Re: Workflow to accumulate individual changes?

["Stephen J. Turnbull" <stephen@xemacs.org>]

Juanma Barranquero writes:

 > Well, if you read the note, you know what am I concerned about: not
 > the time for checking out the files, but the time to get the branch in
 > a runnable state. On my computer, "bzr branch trunk/ test/" is ~35s,
 > while "make bootstrap" is ~20min.

Ah, I skipped over that.

The way that is often recommended to handle that is to have a test
tree, which is setup as a checkout.  So

bzr branch trunk build-test
cd build-test
make bootstrap
make test                 # if you like, but should be OK :-)
for i = 1 2 3; do
  cd ..
  bzr branch trunk fix$i
  cd fix$i
  # hack
  bzr commit -m "fix$i"
  cd ../build-test
  bzr checkout ../fix$i
  make                    # Look Ma, no 'bootstrap'!
  make test
done

YMMV, and caveat hacer: I haven't used this workflow personally, nor
have I tested that my command syntax is correct.

 > (Well, colocated branches à la git would be wonderful for this
 > case...)

Maybe someday, but AFAICS the main candidates for developing such
(Aaron Bentley and Robert Collins) are putting their efforts into
quilt-cum-VCS efforts ("pipelines" and "looms", respectively).

Somebody like you who has a fair amount of DVCS knowledge already (I
don't know how much that is exactly but I'm pretty sure from your
comments that it is sufficient for this) should look at pipelines
(similar to Mercurial queues, and maybe Stacked Git) and looms.
Pipelines really do have a sequential nature to them, which might or
might not get in the way, and AFAIK they don't yet have an mq-like
guard mechanism.  Looms are an original idea of Robert's and some
folks I really respect love them until the fur rubs off.  In
particular, they can sort of be abused in a "guard"-like fashion, I
think.

But it will require experimentation; neither pipelines nor looms are
documented up to Bazaar's usual standards.  (I agree with Eli about
those standards, by the way; that's why I think experimenting with
these requires "sufficient DVCS background".)

 > > If you have a series of one-commit changes, the cheapest way to do it
 > > would be with rebase.
 > 
 > That seems to be the consensus, yes.

The methods suggested above might be useful too.  For one-off patches,
I use mq all the time because Mercurial's support for colocated
branches "should be indented 6 feet downward", at least from my
relatively git-centric viewpoint.  But I also use guards extensively
because I often submit even one-offs for review, so it's not always
the case that writing order is push order.  I don't know offhand how
to emulate guards in bzr.