What is source code control for?

Question

There was a recent question about, effectively, replacing a local source code control system with a "keep all versions" file system or tool.

Many of the answers said in essence that source code control systems are for more than just keeping past versions, even for an individual developer - something I think is correct.

So, the question: What reasons are there for having source code control? And which of those are the most important?

I'm not so much interested in source code control features, but the reasons why those features are there.

Here's a starter for ten, but I'd like to know if I've missed some:

1. Keeping all versions, especially ones that formed a shipped product
2. Enabling a team to edit and preventing (or at least alerting) when two attempt clashing changes
3. Making it easy to see differences between file versions (covering the top two developer excuses: "I didn't change anything" and "my change shouldn't have done that")
4. Protecting against developer accidents (deleting/changing code unintentionally)
5. Protecting against hardware problems (failed disks etc)
6. Allowing development of several different code bases while minimising duplication of unchanged files.
7. Keeping a record of who changed something, and why
8. Enabling experimental changes without breaking the main code base

Why do you use source control?

Answer 1

The biggest advantage that is missing is being able to re-produce the source code that generated an old build.

At build time, you tag the source control with 'Build 4.26'. The next day you start coding Build 4.27. Three months later, when a client says, "I'm using Build 4.26, and there's a bug in the Frickershaw feature. I can't upgrade to any other build because of some changes to file formats you made in build 4.27. Is there anything you can do for me? I'm willing to pay."

Then, you can checkout a branch of the 4.26 source code... fix the Frickershaw feature, and then re-build the package for the user in about an hour or two. Then you can switch back to version 4.39, and keep working.

In the same vein, you can track down the exact point at which a bug was added. Test versions 4.25 for the bug, then 4.20, then 4.10 and eventually find the bug was introduced in version 4.12. Then you look for all changes made between 'Build 4.11' and 'Build 4.12', and then focus on the Frickershaw feature. You can quickly find the source code for the bug without ever debugging it.

Answer 2

A minor advantage of source control for me is that I work on multiple development computers. It is easy to move my work around between machines.

The greatest advantage in my opinion has already been listed. It allows me to sleep at night knowing that if we have to roll-back a change it will be fairly easy.

Answer 3

This has already been discussed quite a bit here.

Good excuses NOT to use version control has over 60 answers.

Do I really need version control? has two dozen answers.

You could probably get a lot of other good ideas by browsing the entries tagged source-control.

Answer 4

I think the main advantage in moving from a "keep-all-versions file system" to a source code control system lies in the fact that the sccs adds structure to all those versions you kept of all those files, and provides you with records of "what was the consistent state of the whole file system at point X".

In other words, "Which version of file A goes with which versions of B, C, D, ...".

And an afterthought (¡!): the special act of committing or checking in makes you think about "what is this?", and the resulting log message can, hopefully, serve as memory...

Answer 5

Search within an entire codebase. It's a killer feature, mainly because the search gets actioned on another machine so you can get on with your work undisturbed.

Which incidentally, is the reason why we didn't change to SourceGear Vault. It can't do this. We're still looking for a SourceSafe-compatible replacement for... well, SourceSafe. Despite what everyone says, it hasn't let us down yet*

* this may just be a matter of time.