bzr revno always an integer, redux and new workflow questions

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
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.

Correct.

> 
> 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
> 
> 

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (Cygwin)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDtKB0ACgkQJdeBCYSNAAPIvgCbB+c82tILXiO3VDY6qwgn8UZE
ch8Ani8mbv0rF/DqmG6KDJ7rNrw7BYY0
=Rkpj
-----END PGP SIGNATURE-----