bzr revno always an integer, redux and new workflow questions
checker at d6.com
Wed Jan 9 08:42:50 UTC 2013
> 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.
Hmm. Does this mean that if I use append_revisions_only=True on the
feature branch I care about being monotonic, then I can skip all this
rigamarole and just always merge from the server repo, and then push to
it? Basically, aro=T would disable bzr pull, which is where my problem
comes from anyway?
Again, I only really care about a single feature branch being monotonic.
Would that simplify my workflow and be close to what I have now? I'd
rather not have a bunch of branches around that I have to test and
build, even with colo.
On 2013-01-09 00:19, John Arbash Meinel wrote:
> -----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.
>> 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (Cygwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
More information about the bazaar