bzr revno always an integer, redux and new workflow questions

[Chris Hecker]

Yeah, it's just that I'm the sole programmer (and build person :) so I 
just develop in the same branch, unless I have something really crazy to 
try, and then I branch again.  So, for now, my development branch is all 
feature branches (except for stuff that I write on the server itself, 
which has another branch), and it's also the trunk, and I guess the repo 
on the server is basically just an off-site backup (except it's also 
where any server side checkins get combined with my local changes).

Like I said, it's pretty amateur-hour for now, but it's also a very low 
overhead workflow, and I don't like friction.  If I add another 
programmer I will probably need to change it up a bit.

Chris

On 2013-01-09 11:29, Gordon Tyler wrote:
> 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
> <mailto: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-----
>
>
>