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: Client tools suck Lack of support for anything to do with directories. The merging model. 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....
Previous Topic
