Hi Tom, I've been using bzr-svn with around 15devs for a few months now and found things not too bad to work with. I've quickly sketched up the workflow we currently use for interests sake. It has some in common with yours, but involves a lot less binding and unbinding generally :). Also, we tend to be pretty "feature-oriented", and as such branch2 tends to be where most of the commits land, and once everything is working properly again, that feature will be merged into svn as one largish checkin (retaining the bzr history of course) 1. do a CHECKOUT of svn into a clean working copy. This is always bound to svn and is essentially a bzr clone of svn trunk (required for merges later on) 2. branch the clean svn copy (branch1) into the working / roaming branch (branch2) 3./4. do all your disconnected commits on branch2 (effectively this is a feature branch). Updates can be merged or pulled in from svn via branch1 (jump into branch and do bzr up) 5./6. the final change set can be commited back into svn enmasse by jumping into branch1 and doing a "bzr merge branch2", then a bzr commit to send the changes to svn Some other thoughts on your binding/rebinding, it looks like a lot of the time you are just trying to get in updates. In this case, bzr merge may be able to do what you want without having to bind & update all the time. E.g., in branch2, "bzr merge branch1" (dont forget to commit!) Either way, bzr with svn works quite well. There are a few major bugs to be wary of if doing multiple developers using bzr on the same svn trunk, but these will hopefully get some lovin' in the next few months (pretty pleeeeeeeeaaaaassse). The only major problem we encountered we've adapted a workflow to avoid... but if you do plan multiple dev's using bzr, let me know and I can probably give some pointers :) Cheers, Philip <div class="gmail_quote">On Wed, Oct 20, 2010 at 6:11 AM, Tom Browder <<a href="mailto:tom.browder@gmail.com">tom.browder@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im">On Tue, Oct 19, 2010 at 11:39, Tom Browder <<a href="mailto:tom.browder@gmail.com">tom.browder@gmail.com</a>> wrote: > On Tue, Oct 19, 2010 at 10:58, John Szakmeister <<a href="mailto:john@szakmeister.net">john@szakmeister.net</a>> wrote: >> On Tue, Oct 19, 2010 at 11:10 AM, Tom Browder <<a href="mailto:tom.browder@gmail.com">tom.browder@gmail.com</a>> wrote: >>> I think I'm in trouble and I know folks here can set me straight again. > ... </div>John, thanks, great blogs. I had seen them early on and didn't know enough then to realize the impact of what you said. I also found that I was wrong about the binding issue. As a consequence I am starting over and including my corrections after the fact as I think I now have a working solution. A recap of my original situation: repo 1: subversion repo on remote host A (accessed via vpn to company network) note that repo 1 is the master source repository (and it is backed up onto multiple disks with svn hotcopy) repo 2: bzr repo on local network host B, checked out from repo 1 repo 3; bzr repo on local network host C, checked out from repo 2 The fundamental original question was how to update repo 1 from repo 2? One point I didn't make earlier was that I am the major user of that company subversion repo (actually a subversion branch) and no one will likely be using it, so I essentially have complete control--i.e., there should be no merge surprises). After John's questions, I went back and did experiments where I added new files in the working trees on all the hosts, changed bindings, and generally mucked around to see how I could get it all to work for my weird (but I suspect not unheard of) work flow. My working concept of operations now is this: 1. Normal operations: repo 2 is unbound I work in repo 3 (my laptop, at home) which stays bound to repo 2 on my home network and commits are done regularly repo2 is backed up periodically by pulling into backup repos on host B (from System Admin Guide, using bzr as its own backup) periodically on host B I will rebind repo2 to repo 1, update repo2 and commit pending merges to repo 1, then unbind repo 2 again 2. Mobile operations (work on laptop while away from my network as well as the company network): I work in repo 3 (my laptop, on the road) which normally stays unbound periodically I will rebind repo3 to repo 1 (a change in parent!), update repo3 and commit pending merges to repo 1, then unbind repo 3 3. Return to home network from a road trip rebind repo 3 to repo 2, update and commit bind repo 2 to repo 1, update and commit, unbind repo 2 return to normal operations [1]