Branching workflow question

[Guy Gascoigne-Piggford]

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
https://url_feature_branch)
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090421/11c19c24/attachment.htm