« How to write a tutorial | Main | Junit 4 »

Migrating to Subversion III

One problem I've felt Subversion had is a lack of GUI tools (plugins for Eclipse and IDEA are pretty nascent and as a result aren't so hot). As a result I've been disinclined to nudge Subversion other than mention I like it. Developers have enough trouble with version control without making them type in weird incantations into a terminal.

Turns out, I'm probably dead wrong and Subversion may never need a decent GUI. I should explain that.

Something strange happened this weekend. I made 60-odd commits to my build manager project in three 4-hour stints. All by alt-tabbing out to the command line and adding a brief comment. Even for a command line / version control wonk like me, that's quite something- ballpark better than one commit every fifteen minutes. I never ever felt like Subversion was in the way. Quite the opposite - it was letting me capture every green bar in a very natural coding rythmn.

All with a VCS I'm still learning how to use. I put some of this down to the atomic, repository-wide commits I mentioned before. I put much of it down to better usability.

Much as I like CVS after using it for years, I've never felt that level of comfort with it - checkins can be a chore. Ditto for VSS. So you put them off, and let what I call the the 'commit area' expand. Doing that can result in you banging into someone else's work and merging. Merging large changes hurts, so you put off the inevitable and end up in a race to the bottom. A common response after being through this pain is to want to lock code. But the truth is, once you're working with a team, you are destined to integrating code one way or another. At best, locking files is a band-aid, at worst it linearizes code development and slows everyone down (by analogy, if you've coded on a project where all roads lead to a database, you've experienced something of what I'm talking about). The cure is not to try and make merging go away (you can't, even with pessimistic locking) but to commit smaller and smaller chunks of work until merging becomes trivial, and in many cases the VCS will take care of it. Integration is so important to development we should be doing it as often as possible. To do this successfully you need the VCS to support you, in exactly the same way that refactoring is supported by a good IDE and testing is supprted by a good framework.

Another effect of commiting this frequently is that the repository version history starts makes sense, and become a useful record - there are no huge bewildering changes to revisit. It also allows you to back out using the VCS. Kent Beck talks about backing out in Refactoring. Many of us will, when we get into trouble, move only forward until we come out the other end, battered, or we get truly lost. (I think this is in part is down to human nature, to search depth first for a solution). But sometimes it's better to throw a change away, fall back to a waypoint, and start over. With frequent checkins you'll rarely be in a situation where throwing work away is too painful to consider. Lose 20 minutes work? That's spilt milk. Much better than wasting half a day hacking your way out of the weeds.

There are tools, and them there are tools that change how you do things in fundamental ways. These are the tools like junit, emacs, idea, lisp, grep/find, araxis-merge, moveable-type, propelx. Add svn to that list. For the first time, I can really see an environment where every green bar test is checked into the repository - whoever glues JUnit to automatic checkins to Subversion is going to make a name for themselves.

[alex reece: feel the sunshine]

October 1, 2003 12:51 AM


Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference Migrating to Subversion III:

» and now for something completely different: the larch from Knut's Weblog
It is now some time ago I read about this new freaky completely distributed revision control system Arch implemented as a set of shell scripts. But that was then. Now it's been reimplemented in C and the frontend isn't called larch , but tla . A CV [Read More]

Tracked on December 9, 2003 04:58 PM