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.

DO NOT PUSH or PULL!

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.