I had a bit of spare time this weekend, so I revisited a project that I occasionally work on – the Jakarta Commons::Net project. From time to time, if my schedule permits (rarely these days, sadly), I’ll visit Bugzilla and try to fix some bugs. This time however, I had a feature to add – I needed support for a parser for a Novell Netware FTP server (truly a rarity these days, however the business school I am currently studying at uses it), and decided to add it. So after a couple of hours, I had a working parser implementation and corresponding unit tests.
Most of Apache these days has migrated from CVS to SVN, and the general comfort level as regards to SVN seems to have increased considerably. I decided to upgrade my (extremely) out-of-date copy of TortoiseSVN while I was checking in the changes. I was struck by a few things:
- TortoiseSVN (and Subversion, more generally) has come a long way. The menu has expanded quite a bit since I last used it, and there are a ton of new features in there. No doubt there are plenty of low-level enhancements that have been incorporated as a result of new versions of Joe Orton’s excellent Neon library, but there are also some more fundamental changes in there.
- Subversion, like CVS, follows the 80/20 rule – the 80% of operations that you will perform repeatedly are very intuitive and easy. This means that some more complex operations can be more fiddly, but most of the time, you don’t notice, because you don’t need them. I contrast this with ClearCase, which I am using at the moment on a separate project, and the difference is pretty stark. Where SVN is elegant, ClearCase is clunky, and where SVN is intuitive, ClearCase is confusing. Of course, ClearCase in its own right is very, very powerful, but it looks and feels like a 20-80% type of product.
- I used to have the odd “lock up” with SVN’s Berkeley DB storage engine (especially if a commit in progress got interrupted), which doesn’t seem to happen any more. The CVS-alike file system backend looks like it will probably be the way forward.
- There were traditionally some doubts about the scalability of SVN, but it hosts some pretty big repositories now.
- The merging/branching process is quite straightforward under SVN. TortoiseSVN even gives you the ability to do a “dry run” of the merge process before actually risking anything – very cool.
There are a couple of things that I’m not 100% happy with, and one is that SVN can’t seem to efficiently figure out how to retrieve a list of revisions for a particular file, so when you try to retrieve a revision graph for a specific file, it seems to want to traverse the revision tree for the entire repository. This results in TortoiseSVN telling you that it will take 5 hours to generate a revision graph! I guess this is the same issue that prevented a port of CVSGraph from happening. Hopefully they’ll sort this out.