bzr revno always an integer, redux and new workflow questions

[Gordon Tyler]

A 'feature branch' is a branch that is short-lived, exists only on a
developer's local machine and is merged back into to trunk/master when the
feature being implemented is done. You shouldn't build releases from
feature branches. Instead you should either build from trunk/master or
create a long-lived release branch from which you build the release and
commit fixes for point/patch releases.


On Wed, Jan 9, 2013 at 4:21 AM, Chris Hecker <checker at d6.com> wrote:

>
> 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!
>
> Thanks!
> Chris
>
>
> 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 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/
>>>
>>> iEYEARECAAYFAlDtMAYACgkQJdeBCY**SNAANCZACg1T/r+**zrVnkABHyUW7OPeI9er
>>> iIoAnRLyDdpjiD0he5Kwa06evzjJK+**HB
>>> =srDy
>>> -----END PGP SIGNATURE-----
>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/bazaar/attachments/20130109/27cb90f4/attachment.html>