January 27, 2008
The State of Subversion Tools
My team moved to Subversion (from CVS) this past November. Because we were in the midst of the holidays at that time, we’re only now beginning to get a sense of whether our first impressions were accurate.
Our first impression was that Subversion’s tools are immature, and will increase the amount of project management/code maintenance that a team lead or release manager will have to perform.
For example, we’d gotten quite used to Eclipse‘s merging capabilities with CVS. Merging was still a manual process and required some effort, and CVS certainly isn’t the right tool for a team that has to maintain many branches, but the tools alleviated much of the pain.
By contrast, the Subclipse plugin provides little value, requires a lot of additional labor to do even the simplest things, and nullifies some of Subversion’s strengths (e.g., moving files as would happen during a refactoring–Subclipse usually does not pick it up as a move, so history gets lost). It also occasionally corrupts one’s local SVN metadata, usually when switching between branches/tags.
I don’t want to dwell on the negatives, though. As far as I’m concerned, a lot of really smart people who’ve probably written more code than I have like Subversion. In such situations, my natural inclination is to assume I’m missing something and continue plodding along.
A co-worker of mine is ready to covertly switch back to CVS under the cover of darkness, and I really have no good answer for many of his complaints. Somehow arguments from authority or appeals to the greater intellect of others are unsatisfying.
What’s really curious to me is that so many common operations aren’t provided by either the SVN command-line, nor, apparently, by any major tool sets. The Subversion book is a truly excellent source of information and contains procedures for just about everything you’d want to do, and all those good recipes are just screaming for automation!
The immaturity of the Subclipse plugin has driven me to the command-line for most things. But already I’ve had to write a number of wrappers to perform common operations:
- First, there was the inane requirement of passing in the full repository URL to every command that doesn’t operate on the local working copy. Even CVS read the
CVSHOMEenvironment variable. (How many times are you working with multiple repositories simultaneously, let alone applying changes from one repository to another?)
- Then, there was the inability to move multiple files at once. Even if you’re working on your local copy and they’re in the same directory (file globs are not supported).
- Then, setting properties has trouble operating recursively unless you want to apply the same property to all files. (Granted, I was originally confused by
propeditand used a wrapper that wouldn’t force me to fire up an editor. Then I discovered
propset, whose limits are fewer. Why do we need two?)
- Then, there was the inability to pull in specific change sets (revisions) from a divergent branch, which I call a “pull” operation. (This is something that ought to be easy from within Subclipse.)
- Then, there was the need to do all the grunt-work necessary to undelete a previously deleted file.
- Finally (so far), there is the inability to see all tags applied to a given file. My wrapper is slow (it has to check every friggin tag), but it works. Unless the file has been moved.
I still find myself liking SVN. I like being able to move files and directories around the hierarchy. I like that directories are versioned, so I can see a history of files that have been added and deleted. I like being able to easily recover a deleted file.
From a project management perspective, I also like being able to query the branch and see the whole history for that branch. I can even go to the very top and ask for the whole history of the entire friggin repository, including all branches and all tags. With a good filter, it’s even readable.
I don’t blame the SVN authors for creating basic building blocks and limiting the verbs and options available. The goal from their perspective is probably approachability. And they’ve built a great command-line help system, which surpasses just about every tool I’ve ever used.
So where are the mature tool sets that use these building blocks to add significant value?
SVN is now 7 years old, and has been a de facto open source standard for going on 3 years. Will SVN be supplanted by its successor before mature tools develop?
What is your favorite tool?