bzr revno always an integer, redux and new workflow questions

[Chris Hecker]

> 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 major.minor.build 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:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
> =:->
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (Cygwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iEYEARECAAYFAlDtMAYACgkQJdeBCYSNAANCZACg1T/r+zrVnkABHyUW7OPeI9er
> iIoAnRLyDdpjiD0he5Kwa06evzjJK+HB
> =srDy
> -----END PGP SIGNATURE-----
>