« ActiveMQ: RESTful JMS, sort of | Main | Right Services, Wrong Tools »

Migrating to Subversion IV

I'm coming to the end of a 1 year experiment with Subversion; initially it was meant be a six month test where I would move some of my own projects onto Subversion, and run with it. That got extended to 12 months, which sounds like a long trial time, but picking the right version control tool is deeply important to me. Version control is life support for programming - a year is worth it.

I believed a year ago that CVS would die off; it would be supported and widely deployed, but no significant development would ever take place. The problems I had would never be solved unless I fixed them myself. Nonetheless, I would come under the banner of CVS advocate. I've invested a lot of time understanding it, explaining it, and developing processes around it. The CVS blockers I've run into again and again with folks are:

  1. Client tools suck
  2. Lack of support for anything to do with directories.
  3. The merging model.
  4. Commandline phobia.

Let's go through each of these, with something of a Java slant:

Client tools suck. This used to be a reasonable argument. Now IDEA and Eclipse blow it away and have done so for years. Their support for CVS is stellar. Eclipse remains intalled of my laptop purely for its CVS support. WinCVS is not a bad tool, it's just not great (it used to be terrible before 1.12...). A lot of people sing TortoiseCVS' praises - on Win2K it slowed my machine down and Windows Explorer crashed constantly - on XP it's fine. Lack of CVS tools are not a reason to migrate away from CVS.

Lack of support for anything to do with directories . This is the one of the first complaints Java programmers will have with CVS. No argument, CVS has zero support for folders. And it's never going to, imo. I think what happens here is you get used to it - when I first moved to CVS, it took nearly a month to get oriented to its file-centricity. Still that's no excuse; CVS sucks here.

The merging model. Ah, well. All I'll say about this are two things. You always merge, even with a locking system. Reliance on locking is masking an unhealthy non-viable software process. CVS does the right thing here, but its tagging and branching model is so obtuse and confusing you might never notice.

Commandline phobia. I'm coming round to this view. If you don't want to have to use a command line you shouldn't have to. Plus given CVS' per file checkin model, you invariably end moving up and down the directory tree. This is ok for C, no good for Java which tends to have deep tree structures.

I choose Subversion as I felt could adress all the issues above, while not incurring expense. Technically it supports atomic commits, directory based versioning and its web interface lends itself to tool support. It even solves yoyo on the command line.

So, how did it go? In June I will write a full review of Subversion. But in short: Subversion is an excellent tool and I'm actively moving all projects off CVS.

A year ago, I said:

it's just a matter of time before one of the main sourcecode hosts support svn repositories along with CVS.

Despite being something of a content free prediction, that hasn't happened yet. But - it seems the ASF Geronimo J2EE project will migrate to Subversion alongside its move out of the Apache incubator. I expect this will bootstrap Subversion usage within the OS java community and result CVS use withering. And when a concerted effort is made to integrate Subversion with Eclipse and IDEA it will be game over for CVS; Subversion addresses too many issues Java developers have for it to remain relevant. Given adoption in the OS community, enterprises will follow suit with a ~2 year lag. That tees up Subversion for mass adoption around 2007.

May 28, 2004 01:52 AM


Robert Sayre
(May 28, 2004 02:00 AM #)

Cocoon is moving soon as well.


and Twisted Python is already there


Henry Story
(May 28, 2004 09:04 AM #)

To all those reading this, you can vote or contribute to the IDEA subverstion integration here:


Jason Carreira
(May 28, 2004 09:08 AM #)

Ever used Perforce? We use it at work and it's just SOOO much faster / more powerful / easier to use than CVS that it makes me cringe to have to do anything more complex than checking in changes in CVS...

(May 28, 2004 09:20 AM #)

With what little use of subversion I have had, I agree that it is well suited for future development projects for many of the reasons you have cited above. Things about svn I would like to know more about are:
1. has a best-practice emerged for a release-based development model emerged yet?
2. how have development teams taken to using svn having migrated from CVS? to this end, i'm looking forward to your fuller review of svn next month

There are also other file-based problems with CVS which I could add to your list of CVS-blockers: moving a java class from one package to another is a hassle in CVS and, what's more, all revision history is lost. And also, on large codebase's, with a large number of files or tags, performance degrades significantly.

All this notwithstanding, I do believe we will see CVS around for a long time still:
* It is tried and tested (which counts a lot in those organisations which suffer from inertia)
* for a lot of people, CVS already satisfies their requirements, so may be they do not feel the need to upgrade
* and because of the sheer size of the installation-base

Jamie Lawrence
(May 28, 2004 11:01 AM #)

I believe Berlios [http://developer.berlios.de/] offer Subversion hosting but definately we need more of it, and more client support. TortoiseSVN is pretty good on Win2k or XP but otherwise there is a lack of clients. I've been using svn for well over a year now and have never lost any data or had significant problems with it. Even migrating through svn database format changes, between the various pre-1.0 versions, was fairly simple.

The only reason cvs is still around is because of its dominating presence rather than any technical advantages.

Ryan Daigle
(May 28, 2004 08:46 PM #)

One thing I like about CVS is that it's file based, not db based like SVN. There's just a level of comfort in knowing that if everything goes to hell, you can always go to the source and start fixing stuff.

In addition, I prefer CVS's method of tagging and branching. Should less-inclined users really have to know in what directory structure you place this tag vs. this branch?

(June 5, 2004 07:21 AM #)

I haven't figured out a good process for branching and merging on Subversion. It wasn't all that great on CVS either but at least there were a lot of recommended practices. It's not obvious how to do it well. For now, I'll copy the trunk to a branch and copy it to a start tag, modify the branch and the merge using the start tag as a reference point.

For example, let's say I've got to work on bug 57 and I think it'll be complex enough to deserve a branch. I'll svn copy to branches/bug_57 and branch-tags/bug_57/start. Then I'll fixup bug 57 in branches/bug_57. Then I'll merge branch-tags/bug_57/start branches/bug_57 with the trunk. Then commit the merge.

It doesn't feel smooth. Due to my CVS background, it also feels very wasteful. Two copies for each branch feels excessive. But I keep convincing myself that it's not the same as CVS. It's tough changing my old mental model to the Subversion one.

Trackback Pings

TrackBack URL for this entry: