bzr revno always an integer, redux and new workflow questions

John Arbash Meinel john at
Wed Jan 9 08:19:41 UTC 2013

Hash: SHA1


> So, I think I want to turn on append_revisions_only=True on the
> server. I'm just a bit confused about my workflow then.
> I have to have a clean branch on each of the machines I merge into
> then, before pushing to the server, right?  So, I have:
> - server repo, append_revisions_only=True
> - client a - feature and trunk branches - client b - feature and
> trunk branches
> I do a feature on client a, checking in a bunch.  On a's trunk
> branch, I pull from the server repo, and then merge the feature to
> it.  Then I can push to the server repo, right, because it's a pure
> superset?  And pull to the feature branch to update it.  Same on
> client b.


> Should I use colo to do each client?  Is it working well enough?
> What's the workflow then?  It sucks to have to have two branches
> per client, but I guess that's the price I have to pay?
> Will this keep a's feature branch with a monotonic revno?  That's
> what I need.

a's feature branch (vs the trunk branch)? Pull and push are the only
way to break the 'monotonically increasing' behavior. So if you use
"merge & commit" to update a feature branch, it will always have
proper increasing values.

In your above scenario, I would probably actually make the 'trunk
branch' a checkout (bzr checkout $TRUNK). In that case, instead of
doing "bzr pull; bzr merge ../feature; bzr commit; bzr push" you would
do: "bzr up; bzr merge; bzr commit".

The main thing is that in a checkout, commit makes the commit + "push"
an atomic step. The commit won't succeed if it can't update the remote
branch tip. Then you don't have a push that may be out sync and
rejected. Or might rollback the revno, etc.

I can't speak a lot about colo support. I believe Martin Packman is
using it, and it works fine though it lacks a bit of polish. I
personally have used local lightweight checkouts in a shared
repository for years now. Which is roughly what colo is supposed to
give you, except the group of branches is underneath .bzr.

> Thanks, Chris


Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined -


More information about the bazaar mailing list