bzr-svn for those stuck with svn servers...

At work I need to interact with an svn (1.4) repository, but honestly I'm so spoiled by bzr that it just drives me nuts, particularly the (frustratingly frequent) situations where I miss a particular change-set/revision when merging into my tree and wind up reverting someone's changes.  The VCS should bloody-well track what revisions are missing, says I.

So, I've been using bzr-svn and bzr-rebase to bridge the gap, and so far it has been quite workable, with a few caveats.  The pattern:

  • bzr init-repo # create a repository which shares data for all your branches/checkouts
  • bzr co http://server/path/to/repo/trunk
  • bzr branch trunk working

the co takes an extremely long time (for some of my personal projects it takes hours, enough to make it worth converting the project to bzr as soon as it finishes), but it eventually finishes.  Now, your colleagues are going to be committing their changes to trunk, to pull them in (I suggest doing this frequently, which is not something I suggest with svn 1.4):

  • cd trunk
  • bzr up
  • cd ../working
  • bzr rebase

which moves your commits to being made against current trunk.  Be careful with bzr-rebase, read the docs and understand what you are doing, you can lose your changes if you are not careful. Keep hacking until you're ready to commit to trunk.


While this would normally be fine with bzr, and seems to "work" with bzr-svn, bzr-svn appears to want to modify every revision in the whole SVN repository with its metadata so that other bzr-svn users can work with you using direct bzr to bzr operations.  Honestly I've never let it try this (ctrl-c ctrl-c ctrl-c argh!), as I'm pretty sure that would (rightly) tick off all the svn users.  Instead, use bzr merge to pull the changes in:

  • cd trunk
  • bzr up # if there are changes re-rebase
  • bzr merge ../working
  • bzr commit

since you've rebased onto trunk, your merge should be clean.  There are going to be a lot of extra properties added to the svn commit (enough to make other users go "yech" when they look at the Trac view), but that's more than made up for by not having to manually track merged change-sets.

If I didn't get annoyed by git's command-line interface I could use that instead (one of our other devs does that), but I want to *reduce* the total pain felt.


  1. Dan Villiom Podlaski Christiansen

    Dan Villiom Podlaski Christiansen on 08/15/2010 10:46 a.m. #

    You might want to check out hgsubversion :-) The UI should be even simpler, and we don't insert *any* unusual revision properties. The only major drawback is that we don't have merge support, yet.

  2. Brian Harring

    Brian Harring on 08/15/2010 4:45 p.m. #

    Lack of merge support kills the main benefit of bzr-svn over just using svk I'd argue.

    Personally, I'm *extremely* reliant on merge support- I use bzr-svn when I'm working on feature branches of svn, merge support (the auto tracking of what has been pulled in already specifically) is what makes svn branches sanely usable.

  3. Mike Fletcher

    Mike Fletcher on 08/15/2010 5:21 p.m. #

    Hmm, maybe I missed something there. Do you mean merge support as in being able to pull from N branches into your working copy (as opposed to just from e.g. trunk)? I tend to do the "feature branch" pattern, always pulling from trunk (rather than from other feature branches or the like). I'm not really using a decentralized model in this setup, just using a merge-tracking tool so I don't have to tracked merges manually. That said, maybe I should look at SVK if it can handle N-way merge-tracking on an SVN 1.4 server. Haven't needed it yet, but it might come up some day.

  4. Jelmer Vernooij

    Jelmer Vernooij on 08/15/2010 7:40 p.m. #

    bzr-svn supports not inserting any unusual revision properties, it just means that pushing your bzr revisions into Subversion is no longer a lossless operation.

    Some information (renames, revision ids, authors, bug metadata) can't be represented in Subversion natively so bzr stores this in custom revision properties.

    If you don't want bzr to set these revision properties, use "bzr dpush" rather than "bzr push". That said, these properties are harmless and are pretty much invisible.

  5. Jelmer Vernooij

    Jelmer Vernooij on 08/15/2010 7:43 p.m. #

    For what it's worth, newer versions of bzr-svn will not remove existing revisions from your mainline unless you explicitly tell it to.

    If you have a recent enough version of Subversion (>= 1.5) bzr-svn will also no longer set any file properties but will instead use revision properties, which are not as visible as file properties and don't require as much data.

  6. Mike C. Fletcher

    Mike C. Fletcher on 08/15/2010 8:28 p.m. #

    Hmm, hadn't realized that was what dpush was for. I guess I'll have to make the trunk a branch rather than a checkout to make use of it (i.e. to be able to push from my local trunk to the svn server).

    Being stuck on svn 1.4 isn't going to change for the time being, likely. Thanks for the pointers.

Comments are closed.


Pingbacks are closed.