bzr revno always an integer, redux and new workflow questions

[Chris Hecker]

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

Chris


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