Subversion and CVS
This post is more so that I’ll be able to find the articles I just read. I can see myself a few months from now scrounging through Google because I sort of remember something relevant to a CVS-to-Subversion migration project, but not knowing exactly what it was. This blog post is to save that half hour on Google.
AskSlashdot has a post with a link to an O’Reilly piece on Subversion and how it compares to CVS.
Subversion just hit 1.0 and is designed to be a modern replacement for CVS. The SVN repository uses a Berkeley DB to hold the metadata for versioning, unlike CVS’s storing such information in the individual files themselves. This makes branching and tagging more efficient, as well as allowing atomic commits. There’s also an efficient binary diff, so binary files like our MS Word project spec files can be stored with less headache. SVN should have CVS-like commands, so the transition at the command line shouldn’t be that different from what the developers are used to.
In terms of what has to happen for us to start using SVN, we’ll need a Windows GUI, a web interface and conversion tools.
For the GUI, the ORA article mentions TortoiseSVN (Windows Explorer extensions) and Subclipse (Eclipse plugin). These have to be looked at. Tigris.org also is working on RapidSVN, a cross-platform GUI for SVN.
The web interface should be relatively trivial, as recent versions of ViewCVS has built in SVN functionality. Also, SVN promises to be WebDAV compatible, so any Apache with mod_dav module should be able to show the repository.
For migration, SVN apparently comes with cvs2svn, which is under development and may fail on CVS repositories with complicated branches. This link also mentions a few other things, as well as providing a link to general Subversion documentation, probably as a mirror to the main project site.
We’ll probably set up a test once 1.0.1 comes out.