bzr revno always an integer, redux and new workflow questions
checker at d6.com
Wed Jan 9 21:13:31 UTC 2013
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.
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!
> 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
> 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
> 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
> If I was acting like a real programmer, I'd have a build machine
> 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
> that contains the revision id in case this happens again. :)
> 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
> 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
> 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.
> 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.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (Cygwin)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
> -----END PGP SIGNATURE-----
More information about the bazaar