18

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?

37 accepted

Oh my god, 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.

8

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.

3

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?

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.

2

yes, yes it should

2

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.

2

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.

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.

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.

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

1

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.

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.