Saturday, June 20, 2009

Subversion fail!!

The problem:
I need to refactor the directory structure of an active repository. This refactor could take some time

I am a big subversion fan. I've never really caught the distributed revision control bug. I think I like the idea of having an official location and copy of my repository built into the tool. I also understand repository permissions in subversion better. Distributed just seems too loose for my tastes.

I've recently however become a fan of Bazaar. It seems like they tried to make the idea of a central official copy and bake it into the tool. One of the unique features of bazaar is its true rename support. Git and mercurial just guess, but do a good job at it. Subversion just fails, completely.

Subversion just performs a copy, delete to mimic a copy. The problem with this approach is, file identity is lost. That means history can be broken, but svn does a good job at guessing here. It also means that updates can do weird things.

Enough rambling, here's the short of it. NEVER rename in svn. If you must rename, make sure no one has uncommited work that deals with the renamed file (this include every file under a directory rename), delete all branches.

People with uncommited work will end up in a weird situation where their file with changes isn't updated, instead svn creates a new file to reflect the renamed version with none of their modifications.

Branches are just hosed. Subversion doesn't lend itself to long term branching. Version 1.5 took a step in that direction however with merge history. None of that matters however if just one file is renamed that the branch has modified. THERE IS NO WAY to merge a branch to trunk or vis versa if a rename has occurred.

So the simple solution, avoid long term branches, perform renames only with much caution.

But what if you cannot stall development to refactor the directory structure? Wisdom would suggest, make a branch, perform the renames there, updating from main as you go. Once everything works, merge back to the trunk. That's what branches are for after all. As pointed out earlier that wont work because of the the abysmal state of rename in svn.

One defense: this is a free open source project, cut them some slack.

Ok, how long should we wait for them to fix this since it's such an obvious error? Let's be generous and give them 5 years. The development team realized they had made an error when implementing rename in 2002. Worse still the true rename is scheduled to be included in version 1.8. But even that means nothing! It was also scheduled to be fixed in 1.4, 1.5, 1.6, and 1.7. There is no 1.9 scheduled. So saying it will be fixed in 1.8 is just the official way of saying "not yet". We're looking at a 2010 fix at the earliest.

Subversion fail!


The solution:

All is not lost. Remember bazaar has true rename support. Even more importantly, it has a subversion backend plugin. bazaar-vcs.org/BzrForeignBranches/Subversion

Install Bazaar.
Install bzr-svn.
bzr branch
bzr push
perform refactoring, merging from trunk as needed.
bzr ci as often as possible
bzr checkout
bzr merge
bzr ci

Other advantages.
  • Long term branches
  • local checkins and repo checkins.
  • regular svn users can easily checkout the branch and use it. (Though I'd be wary of them doing any renames, who know what svn would screw up).


Post a Comment