Sub Version

Subversion is a VersionControl system that is a compelling replacement for ConcurrentVersionsSystem. The software is released under an Apache/BSD-style open source license. SVN is a lively project, and many of the past CVS developers have jumped ship to go work on SVN.

: http://subversion.apache.org/

Relative to CVS, SVN adds:

Directories, renames, and file meta-data are versioned.
Commits are truly atomic.
Branching and tagging are cheap (constant time) operations.
Use of HTTP-based protocol.
Better handling of binary files.

SVN (and CVS) does not have:

Exclusive check-outs. NOTE: latest version of SVN (1.2) supports locks!
Sophisticated task-based changeset management.

For comparisons to every other SCM tool on the planet, see http://better-scm.berlios.de/comparison/.

For individual experiences with SVN, see SubversionExperiences.

Here are some additional tools that work with SVN:

TortoiseSvn, at http://subversion.tigris.org/
SubClipse? for the EclipseIde, at http://subclipse.sourceforge.net/
NetBeans IDE Subversion integration at http://subversion.netbeans.org/
TracProject, at http://trac.edgewall.org/, has TracWiki built in!
Ankh for VisualStudio, at http://ankhsvn.tigris.org/
SvkVersionControl - a distributed version control system built on top of Subversion

Repository-wide version number and atomic commits

For users of CVS, this is a big leap forward. It solves several problems you may not have realized you were suffering from. In particular, file and directory renames in CVS are handled as one or more deletes followed by one or more adds. The revision history is separated, since CVS doesn't have the ability to understand that the file is still the same file, after the rename. SVN fixes that problem.

Another advantage of repository-wide version numbers is that you can easily step forward and backwards through revisions of the project instead of only individual files.

Files don't have versions - collections of files have versions. It is very easy to change between them, and it keeps track of which files have changed and does it all atomically.

No exclusive check-outs

NOTE: latest version of SVN (1.2) supports locks!

For current VSS or PVCS users, this may come as a bit of a shock. Lock-free SCM is popular in the open source community and very large companies because it allows more concurrent development to happen. (hence the name of CVS, ConcurrentVersionsSystem).

As it turns out, lock-free SCM can scale down to pretty small teams as well. If two users change the same file and commit their changes, the second user will be notified that there is a conflict. In 99% of the cases, the system will offer to automatically merge the changes. If there is an irreconcilable difference - the two users changed the same line of code, for example, the system will pop up a merge tool so that the user can manage the merge. This works best on well-factored source code, where the likelyhood of two users changing the same line of code simultaneously is small. The likelyhood of conflicts also drops when you CommitEarlyAndOften.

If you are in a very small group, or you expect that users will often create irreconcilable code changes, then SVN may not be the tool for you. This may also be an early-indicator of PoorCommunication? or PoorProcess?.

Better than CVS

The core SVN team consists almost entirely of ex-CVS developers. That should say something about how it relates to CVS. It is very similar to CVS, so migrating to it should be relatively painless for existing CVS users. But the design is changed to deal with some old nagging CVS problems.

Here are a few corner cases to highlight the improved design:

Make a branch. Then modify the same files in both branches and also change their names in both branches. Merge the branch. Next, remove a file in one branch, commit, then locally edit on another branch and do an update. CVS chokes. SVN does not choke.
Run "cvs log | more" and then go to lunch. All checkins stop. SVN does not have this problem.