January 27, 2008

The State of Subversion Tools

Posted in Software tagged , , , , , at 4:06 pm by mj

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:

  1. 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 CVSHOME environment variable. (How many times are you working with multiple repositories simultaneously, let alone applying changes from one repository to another?)
  2. 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).
  3. Then, setting properties has trouble operating recursively unless you want to apply the same property to all files. (Granted, I was originally confused by propedit and 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?)
  4. 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.)
  5. Then, there was the need to do all the grunt-work necessary to undelete a previously deleted file.
  6. 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?



  1. mkb said,

    I’m forgetting whether you run Linux or Windows on your work machine, but many windows users like TortoiseSVN. I’ve been very happy with the SVN support in IntelliJ IDEA, though to be fair I haven’t tried it for merges. I’ve grown accustomed to doing merges from the command line

    Subversion 1.5 will track merge history which should make merges close to painless provided they are done often enough. Assuming that 1.5 works well, it will start to give Perforce a run for its money though of course the GUI tools will still need to catch up.

    In general, I have found that the open source movement does much better with command-line and sever software than with GUIs. Perhaps the breadth and level of detail required call for a paid staff. Or perhaps GUIs simply require people with additional skillsets (graphic design, interaction design, writing, etc.) who are less drawn to open source than the coders are.

  2. mj said,

    Windows users around here are also using TurtoiseSVN, and they’ve had similar issues. Although I don’t think Turtoise has yet corrupted anybody’s local SVN metadata.

    I am starting to hear good things about IDEA’s SVN support. I have an old license, but will give a go on the new version. Interestingly, the reason we originally semi-standardized on Eclipse was IDEA’s poorer CVS integration.

    I’ve also just read good things about the Subversive Eclipse plugin, which I’ve yet to try.

    I think you’re right about the types of people drawn to develop graphical skills aren’t usually drawn to contribute to open source.

  3. kenton said,

    I’d recommend subversive, its merging tools are much better than subclipse, and subversive is eventually going to be included in eclipse

  4. […] tagged source control, svn, tools at 7:57 am by mj Since I complained earlier this year about the state of Subversion tools, I’ve been thinking about a follow-up that’s a bit more […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: