Well the odds are very high that both feature and dev branches might be pretty long lived with multiple merges going back and forth, I've got used to the habit of merging to the dev branch, tidying up, and then merging to the feature branch. After those changes are committed, I merge --pull to the dev branch, and keep going. Part of this is because whilst bzr makes creating new branches trivial, pointing my dev tools (IntelliJ in this case) at a new branch takes what seems like ages. FYI bzr info says that we have ~24k files, 2771 versionsed directories and 2253 revisions. Guy <div class="gmail_quote">On Tue, Apr 21, 2009 at 4:41 PM, Robert Collins <<a href="mailto:robert.collins@canonical.com">robert.collins@canonical.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div class="im">On Tue, 2009-04-21 at 15:13 -0700, Guy Gascoigne-Piggford wrote: > > 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. </div>Committing to trunk is one of the major reasons for checkouts, and why checkouts with history are very useful; I use them all the time ;). For your process I would do: cd trunk bzr merge ../dev_branch fixup conflicts regression-test if needed bzr commit That seems much more direct. -Rob </blockquote></div>