bzr revno always an integer, redux and new workflow questions

Chris Hecker checker at
Wed Jan 9 09:21:55 UTC 2013

Yep, this seems to work perfectly for my use-case.  Damn, wish I'd done 
this a while ago!  bzr is so flexible, it's great!


On 2013-01-09 01:01, Chris Hecker wrote:
>> I'm not quite sure why that feature branch isn't actually your
>> trunk. But yes, it does sound like it would solve your situation.
> Well, I may also be using the terms incorrectly.  This is my first dvcs
> project, and I'm not very d, if that makes sense.  So, I run it mostly
> like a p4 or svn project, where I code on my laptop, and then check it
> in, and then push to the server.  Of course, I also have a branch on the
> server that I work on for server side stuff.  That's the one that
> stomped the revno locally when I merged there, and then pushed to the
> main repo, and then pulled.
> I build releases in the feature branch, so the revno gets snapped there
> to make the build number for the version number in the
> exe.
> If I was acting like a real programmer, I'd have a build machine that
> would make the builds, or at least a separate branch on my laptop that
> is just used for that, but I don't do that right now.
> I will try aro=T locally, because now that I've explained everything and
> you've explained everything, I think that's exactly what I want.  I
> could care less about the revno on the server in either the main repo or
> its branches.  I'm also going to make a field in the version resource
> that contains the revision id in case this happens again.  :)
> Thanks!
> Chris
> On 2013-01-09 00:53, John Arbash Meinel wrote:
>> Hash: SHA1
>> On 2013-01-09 12:42, Chris Hecker wrote:
>>>> 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
>> I'm not quite sure why that feature branch isn't actually your trunk.
>> But yes, it does sound like it would solve your situation.
>> John
>> =:->
>> Version: GnuPG v1.4.12 (Cygwin)
>> Comment: Using GnuPG with undefined -
>> iIoAnRLyDdpjiD0he5Kwa06evzjJK+HB
>> =srDy
>> -----END PGP SIGNATURE-----

More information about the bazaar mailing list