Version control is not about versions

We call it version control, but it's really not about version control.

In the distant past, we lived without version control. (Or automated tests. Or e-mail.)

While programs were written by single individuals, things mostly worked. But even a single individual can make mistakes, and a previous version of the program is helpful. The ability to "go back in time" is useful, and a copy of yesterday's version (or last week's, or last year's) is easy enough to keep.

Once program teams became larger than a single person, we needed ways to coordinate the activities of the different team members. It was all too easy to store the code in a common place, let everyone make changes, and have interleaving reads and writes that lost changes.

Thus version control was invented. Version control did two things: it kept previous versions of the code (providing the "back in time" capability for everyone) and it serialized access to files, so all changes were kept.

Modern, professional projects today use version control of some sort. (SourceSafe, CVS, subversion, Git, ... the list is a long one.) People think that it is a necessity (which it is) but don't understand the real reason for selecting a version control system.

Most people think that version control systems (VCSs) are about versions. They focus on the "back in time" capability of a VCS.

But VCS is about more than "back in time".

Your version control system defines how the team works. It sets the rules for interactions between team members. If you select a "locking" VCS (or configure one that way), you define a process that forces team members to wait for files to become "unlocked" to check in their changes. If you define a process that does not lock files, then you force team members to merge changes with concurrent changes.

The VCS can grant and restrict access to different branches of the storage "tree". You can use this feature, or you can allow all team members access to every area. In the latter case, you trust team members to make the right changes. In the former case, you don't trust your team members.

Here's the pattern that I've seen: shops that use agile methods (daily builds and  automated tests, specifically) put less emphasis on their VCS. They let all team members check in files anywhere. They expect team members to run tests prior to check in. They expect their team members to do the right things. They trust their teammates.

Teams that use waterfall methods (infrequent builds, limited or no automated tests) use their VCS as a control mechanism. They restrict access to certain areas, to let only the select trusted few make changes in those areas. They expect their team members to do the wrong things, and use their VCS to guard against mistakes. They do not trust their teammates.

I'm not saying that one of these is better than the other. (Although in my personal experience I prefer the former.) Both have their advantages. Which you choose depends on your management style and your trust in your people.

Version control is about the team, how it interacts, and how much it trusts itself. And how much the managers trust the team.