40

Possible Duplicate:
Version control for independent developers?

I've heard statements to the effect of: "Well it's just me working on this project so I don't need to put it under source control" as well as, "There is no need to work version controlled on this project, it's so small".

It is my opinion that no matter how small the project is, so long as it's adding value to the client (and they are paying for it too) that we, the developer(s), should version control it; especially since its company policy.

Am I insane or does my standpoint make sense.

Question: Should development work always be version controlled?

Improve this question
12
  • Where do you store all your files, how many computers you use for work (not as remote terminals!) and how much of unused.c, stub.pl, hacking.txt, tmp.txt files you have? How you track progress?
    – kagali-san
    Dec 17, 2010 at 2:08
  • 14
    Am I insane? No I am :-) and the answer to your main question = Yes, ALWAYS :-)
    – Jagmag
    Dec 17, 2010 at 2:09
  • 1
    Always is a very strong word. I can think of some scenarios where it is not strictly necessary, but absent reasons not to, I would always recommend doing it.
    – Matt Davis
    Dec 17, 2010 at 2:12
  • @InSane: no, you are ;-P
    – zerkms
    Dec 17, 2010 at 2:12
  • 4
    Duplicate: Do I really need version control?, Using Version Control for Home Development?, Why should I use version control?. Please do try to search SO first before asking a question. The above were quite easy to find.
    – gnovice
    Dec 17, 2010 at 15:43

11 Answers 11

Reset to default
89

Oh wow, yes.

I use both SVN and Git and I cannot tell you how many times they've saved my ass. More Git than SVN, but let's not start flamewars here. This is on projects I work on by myself, as well as projects I work on with other people. No excuse not to, really.

As a human, I'm basically entitled to do stupid shit all the time. By using version control, I can merrily carry on my way doing awesome things and committing at intervals where it makes sense. When I do something incredibly stupid then I can simply rollback my changes to the last point where I committed. Even with Git, I can roll back specific chunks of changes to a file rather than the whole file.

My version-control (ab?)using work flow, as a Rails developer (and yes, I know you use C#, same flow applies. Just sub my git commands for your tfs commands), goes like this for a brand new project:

  • Grab a new feature off Pivotal Tracker and figure out what the hell it's supposed to do. Also known as Client-to-English translation.
    • Create a brand new directory for the project and then immediately:
    • git init
    • git add .
    • git commit -m "Initial setup for [project]"
    • git remote add origin [email protected]:radar/project.git
    • git push origin master

I now have a Git repository ready for me to commit to, with a master branch. This master branch should always remain "pure". The tests should always be 100%-passing-no-excuses-or-somebody's-going-to-get-fired-slash-very-badly-injured-did-I-mention-no-excuses on this branch. If the feature is adequately complex enough (taking me longer than an hour or two or if the change is going to be more than a single, sensible commit) I will create my own branch using git checkout -b [feature-name], if not I will work on master.

In this branch, I can do whatever the hell I like. master's still going to be "pure" and I can effectively trash the place and then git checkout . to get it all back. It's in this branch that I develop the new feature, making incremental, sensible commits along the way. Made a page where a user can fill in a form and then something to handle that form? That's a commit. Added a new function to a class and tested it? New commit. I may be inclined to push this branch up somewhere so other people can work with me on it, in which case I would git push origin [feature-name] and then they could clone the repository and git checkout origin/[feature-name] -b [feature-name] to get my changes and we could work together on it.

When I'm done with the feature, I run the tests on the [feature-name] branch. Then, I can go back into the master branch, make sure everything's still "pure" by running the tests, and then git merge [feature-name] to merge the branch into master. Then I run the tests again to make sure it's still "pure" (remember, no excuses) and finally I push my changes to the master branch on GitHub.

Rinse, repeat.

Without version control, I would be utterly lost. I would do stupid shit and then spend quite a lot of time manually rolling it back and not being sure if I've got it all or not. Version control is a great tool to prevent stupidity (as is testing, but that's a tangential topic) and I really, really strongly encourage it.

No excuses.

Improve this answer
9
  • 3
    well said Ryan...
    – RameshVel
    Dec 17, 2010 at 5:38
  • +1, though I use bzr (it stays the hell outta my way to let me get things done)... ;-)
    – Michael Trausch
    Dec 17, 2010 at 8:16
  • YES. Workflow integration is an absolute must.
    – Forkrul Assail
    Dec 17, 2010 at 8:22
  • 3
    Client to English translation. I'm putting that in my tool box.
    – kurtnelle
    Dec 17, 2010 at 15:16
  • so that's a "yes" then?
    – ozz
    Feb 1, 2011 at 16:09
10

Yes, a developer should always use version control, of some kind. Who knows how big a project may become, or how many people may be using it, or what bug you've just introduced. VC should go hand in hand with off-site storage of the project too.

Improve this answer
6

It is absolutely personal decision.

As for me - I put in control version anything. Literally - anything. Doesn't matter - is it a what-to-buy-in-a-shop list, or a project sources.

Improve this answer
2
  • 1
    and ~/.* configs
    – kagali-san
    Dec 17, 2010 at 2:08
  • @mhambra: yes, good point :-) ls -la ~/.hg/* |wc -l --- result: 15
    – zerkms
    Dec 17, 2010 at 2:10
4

Absolutely. If nothing else (and that a BIG if), it frees you to play around with your code without worrying about losing your working implementation.

Improve this answer
3

How much development work can you afford to lose? What happens when you need to back out a change? Sooner or later you will need it.

Improve this answer
2
  • 2
    The response to those statements is "Well we back up stuff don't we? Just restore it from back up". To which I retort "Ok so when was the last time it was was working?..."
    – kurtnelle
    Dec 17, 2010 at 15:18
  • @kurtnelle - Yep. Your disaster recovery plan is only as good as your last test.
    – Mike Chess
    Dec 17, 2010 at 16:51
2

There is absolutely no reason not to do this every time you write code. If you've got git installed, you can even just do this locally for things that you consider throw-away. Basically, if you're going to edit the file more than once, it should go in version control. That simple.

Why wouldn't you do this? It seems like the cognitive load of trying to figure out whether to do it or not is more than the cost of just always doing it. Seriously, what effort would anyone be trying to save here?

The mind boggles.

Improve this answer
1

Yes you should use all the time source control ....

Even if the project is small there is a big benefit of using it. Plus the overhead is practically none if the team know how to use the version control system.

Having some traceability over small project is also important, you can work on same files without stepping on each other toes, it act as backup, etc ... etc ... so why just not use it.

Improve this answer
1

Yes you are right. Version control allows you to roll back to a previous point if you get stuck, and it also allows keeps backups for your code (particularly important for corporate environments). If you feel that, for some reason, creating a repository for this small project is too much overhead then consider using a distributed VCS like git or mercurial to create a repository locally.

Improve this answer
1

You should, and you should also use a source control tool where it is very cheap to do this.

I had a bad habit of not using source control straight away when I used subversion, but with tools such as Git & Mercurial, it is so cheap to get started

Improve this answer
2
  • subversion's pretty easy too: 'svnadmin create ~/repos/myproj; svn import . ~/repos/myproj/trunk'
    – snoopy
    Dec 17, 2010 at 2:28
  • To clarify, I prefer the distributed systems as its easy to create the repo, and then publish it later without much effort, moving subversion repos is definitely more work
    – aussiegeek
    Dec 20, 2010 at 3:03
1

IMHO I'd say it's good practice. I can be a life saver in those casen you've been trying out different solutions and want to back up to a sane version of your code.

I use it even for small personal projects. I've found myself doodling around in my code so many times cursing over the Ctrl-Z not extending far enough back in time.

Improve this answer
1

Anyone that tells you that is an idiot.

Any company that employs a developer (or manager) that says that is not somewhere you want to work, unless you think you can start to change stuff like that.

Honestly, you hear war stories, but I seriously didn't think places like that existed anymore.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.