Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
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 '10 at 2:08
13  
Am I insane? No I am :-) and the answer to your main question = Yes, ALWAYS :-) –  InSane Dec 17 '10 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 '10 at 2:12
    
@InSane: no, you are ;-P –  zerkms Dec 17 '10 at 2:12
3  
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 '10 at 15:43
show 7 more comments

migrated from stackoverflow.com Feb 1 '11 at 15:29

This question came from our site for professional and enthusiast programmers.

marked as duplicate by Anna Lear Jun 20 '11 at 20:07

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

12 Answers

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 git@github.com: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.

share|improve this answer
3  
well said Ryan... –  RameshVel Dec 17 '10 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 '10 at 8:16
    
YES. Workflow integration is an absolute must. –  Forkrul Assail Dec 17 '10 at 8:22
    
Thanks Ramesh and Michael + those who have upvoted! –  Ryan Bigg Dec 17 '10 at 10:32
3  
Client to English translation. I'm putting that in my tool box. –  kurtnelle Dec 17 '10 at 15:16
show 3 more comments

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.

share|improve this answer
add comment

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.

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

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.

share|improve this answer
add comment

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.

share|improve this answer
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 '10 at 15:18
    
@kurtnelle - Yep. Your disaster recovery plan is only as good as your last test. –  Mike Chess Dec 17 '10 at 16:51
add comment

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.

share|improve this answer
add comment

yes, yes it should

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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

share|improve this answer
    
subversion's pretty easy too: 'svnadmin create ~/repos/myproj; svn import . ~/repos/myproj/trunk' –  snoopy Dec 17 '10 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 '10 at 3:03
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment