Workflow to accumulate individual changes?

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

Juanma Barranquero writes:

 > Let's suppose I want to create a local post-23.2 branch where I do
 > want to commit small changes to install on the trunk post-release. I
 > don't want to be forced to create a task branch for every one of them,
 > because they are small changes, and a new branch implies having to
 > bootstrap[1] anew. So I'd like to accumulate the changes into a single
 > branch.

I don't understand what you're concerned about (yes, I've seen the
followup which includes the footnote).  If you follow the procedure
for creating a shared repository (described in BzrForEmacsDevs, among
other places), then all branches under the shared repository directory
share storage, and creating a branch is very cheap (ie, the cost of
copying the tree, which is small since you can use hardlinks).[1]  I
would think this would be fine for anything requiring more than one
commit.  In any case, I think it would be worth trying, you might find
it's perfectly satisfactory.

You can make this slightly cheaper by using "checkout --lightweight"
(but the main cost is still creating the tree).

If you have a series of one-commit changes, the cheapest way to do it
would be with rebase.  (N.B. I can't help you with "bzr rebase"
itself, I've never used it.)  The idea would be to put each commit in
the same branch.  You will almost certainly have exactly one conflict
per ChangeLog you touch, but after that your commits will take place
on top of the previous one, and should be fine (at least, I think bzr
is smart enough not to conflict again).

 > Once the trunk is open again, what would be the procedure to install
 > the changes?

If you follow any of the above, you would just follow the usual
procedure for installing as described in BzrForEmacsDevs.

 > Obviously not "bzr merge ../post-23.2", because that would create a
 > single [merge] commit.

Yup, see attached script[2].  I don't have a plugin, but I have a
script that you can use to simulate the workflow you propose (if
you're on Windows you'll need to .BATify or use Cygwin).  Tested and
works on Gentoo GNU/Linux.  Two workflows I tried unsuccessfully are
also documented there for posterity.


Footnotes: 
[1]  You may need to tune the branch command to use hardlinks instead
of copies.

[2]
# set up a trunk mirror as usual
# test code: uncomment next statement to test
TESTP=t
if test -n "$TESTP"; then
 newfile () { echo $1 > $1; bzr add $1; }
 addlog () { echo $1 > .tmp0; cat .tmp0 ChangeLog > .tmp1; mv .tmp1 ChangeLog; }
 cd /tmp
 mkdir shared-repo
 cd shared-repo
 bzr init-repo
 mkdir remote-trunk
 cd remote-trunk
 bzr init
 newfile ChangeLog
 newfile foo
 bzr commit -m "add foo"
 cd ..
 bzr checkout remote-trunk trunk
fi

# set up your post 23.2 branch
bzr branch trunk post-23.2
cd post-23.2

# hack ... commit ... hack ... commit ... until trunk open
# more test code
if test -n "$TESTP"; then
 newfile bar
 addlog 'add bar'
 bzr commit -m 'add bar'
 newfile baz
 addlog 'add baz'
 bzr commit -m 'add baz'
 # simulate concurrent work
 cd ../remote-trunk
 newfile quux
 addlog 'add quux'
 bzr commit -m 'add quux'
fi

# here's the install procedure itself
cd ../trunk
bzr update
# trunk is now up-to-date
cd ../post-23.2
# durn, in testing the update fails, branches have diverged
# bzr update
# durn, in testing the merge --pull succeeds but leaves you with the
# remote changes at the top
bzr merge --pull

# what I hoped for but doesn't actually work (it creates a true merge
# rather than a fast forward)
# cd ../trunk
# bzr pull ../post-23.2