What We Failed to Do

A number of items on the evaluation and transition plan never happened. We didn't create any local training materials—it didn't seem necessary, given the high quality of Subversion's built in documentation, and the fact that we all knew CVS (see Sidebar: Subversion for CVS users). We ordered printed copies of "Version Control with Subversion" and "Pragmatic Version Control Using Subversion", set up an FAQ page on the Wiki that did little more than collect together a few links to offsite URLs, and left it at that.

Subversion for CVS users

If you're familiar with CVS then Subversion will also seem familiar. This is hardly surprising since Subversion's stated aim is to be a compelling replacement for CVS. So, the terminology is almost identical: you "check out" files from a "repository", you edit them, you "diff" files to see what you—and others—have changed, and you "check in" your changes. You "update" your working copy to merge in changes made by other team members. You can "log" what changes have been made. You can "branch" a project by copying it from the "trunk" into a new place in the repository; similarly you can "tag" a fixed version of a project by copying it into a new place in the repository. You can "merge" changes made on the branch back to the trunk, and vice versa.
If you use the command line client, svn, the command line arguments are often identical to the ones used with the cvs client (svn commit, svn checkout, svn status, svn annotate svn diff, svn log, etc.).
The areas where CVS and Subversion differ are generally where Subversion fixes a CVS deficiency or where Subversion actually manages to simplify things. For example, as already mentioned, Subversion fixes a well-known CVS deficiency by allowing you to move files and directories; and Subversion's transactional model means that a version number (a revision number, in Subversion terminology) is an incrementing integer applied to the repository as a whole, which is easier to work with than the dot-separated version numbers which apply to each CVS controlled file.
More information for CVS users migrating to Subversion can be found here.

Despite encouragement, no-one had bothered to use the trial repository as a sandbox for experimenting with Subversion (apart from the individual actually running the trial). So, the evaluation of the product's usability and basic functionality was down to just one person. Again, this turned out not to be a problem—and we weren't really being lax when you consider how many open source projects have switched, or are switching, to Subversion. We just knew Subversion worked.

We quite deliberately didn't plan any reorganisation or pruning of the CVS repository before importing it: Subversion would allow us to make such changes in a better controlled way, once we got to the other side. For similar reasons, we didn't change keyword expansion properties on import. Again, Subversion allows you to manage such properties better than CVS does, and now was not the time to start arguing whether or not we really thought keyword expansion was a good idea ^[2].

We didn't fix any of our build scripts in advance. As part of the evaluation we'd grepped the source for all such scripts and it turned out you could count the number of scripted calls to cvs on the fingers of one hand. We were confident we could fix these pretty much as soon as our Subversion server went live.

We didn't even bother evaluating any advanced Subversion clients. I used the command line almost exclusively for experimentation: others were happy to defer setting up TortoiseSVN, Subclipse, psvn, etc., until they actually had to.

The one crucial item we neglected from our plan was to perform acceptance tests on the freshly imported repository. Fortunately we discovered the problem with our carelessness almost immediately and were able to recover swiftly.

^[2]It's a bad idea!