Branching workflow question

[Guy Gascoigne-Piggford]

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


On Tue, Apr 21, 2009 at 4:41 PM, Robert Collins <
robert.collins at canonical.com> wrote:

> 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.
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090422/89e060ab/attachment.htm