The development group that I'm part of has been using Bazaar for about 4 months now, with generally excellent results. The tools work well, and tend to do a really good job of not being surprising, our biggest hurdle right now is with integrations, everything supports svn, not much supports bzr. That aside, I've got a workflow related question. We have a product trunk on a central sever, we have feature branches also on a centralized server (a different one, though I don't think that that matters here), and then the individual developers either work on checkouts of the feature branches or on personal branches off the feature branch. My question targets those developers who are working on a branch. We don't really have branch maintainters per se. we have a code review process using Review Board and when the right people have said OK, then the developer is responsible for getting their code onto the feature branch. What we end out doing goes something like this. check in all local changes on the dev branch. (bzr ci) merge from the feature branch to the dev branch. (bzr merge <a href="https://url_feature_branch">https://url_feature_branch</a>) resolve any conflicts then check in the merge. (bzr resolve; bzr ci) switch to a checkout of the feature branch. update it. (bzr up) merge from the dev branch to the feature branch) (bzr merge ../dev_branch) - barring timing issues there really aren't likely to be conflicts, but if there are then we either cycle back to stage 1, or just resolve them here and continue. check in (bzr ci). This works and isn't particularly tricky, but it somehow seems that we're missing something. I noticed that in all of the discussions about checkouts recently, not one of them mentioned using them as a way to manage a merge to a remote branch, and that's pretty much exactly what we are doing. There are a number of reasons whey we ended out doing this. The remote branches are on build boxes and as a general rule dev doesn't have direct access to them. Even if dev did have access, then we'd have to find more standard ways to publicize private branches to merge from, and that's a bit annoying since it varies from platform to platform somewhat. The nice thing about the way that we're currently doing things is that I could document it specifically and it doesn't need to vary from platform to platform. Finally it's important to us that the feature branches and trunk retain their idea of history and don't get a dev branch's version pushed on top of it. I really want to be able to look at a branch history and see what was done on the mainline for a branch and what was merged in from elsewhere, also the folks who are using checkouts for dev work rather than branches hate it when someone inadvertently does a push and screws with their world view (actually this only happened once, but it took quite a while for us to convince ourselves that the code was fine, but that the history was confusing in the extreme). As an aside, I don't think that anyone here actually uses a local checkout to do local checkins, they are always used so that actions can be performed on the remote branch, that said, being able to do log, diff etc. without hitting the network is very useful. So, in summary, is there a better way to manage merging to a remote branch other than checking it out? Or is there a different workflow that we should be considering? Thanks - Guy