Re: Workflow to accumulate individual changes?

[Giorgos Keramidas]

On Wed, 30 Dec 2009 22:34:07 +0100, Juanma Barranquero <address@hidden> wrote:
> 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.
>
> Once the trunk is open again, what would be the procedure to install
> the changes? Obviously not "bzr merge ../post-23.2", because that
> would create a single [merge] commit. Will I be forced to repeat "bzr
> log" and "bzr merge --revision=REVID ../post-23.2" for each change?
> That seems a bit cumbersome. Is there any way to simplify it? Perhaps
> a plugin?

Hi Juanma,

If the changes are separate commits, it *may* be simple to avoid a
gazillion merges (one for each small change) by using the rebase plugin
of bazaar.  This way instead of having a history like

      [1]         [2]         [3]
     /           /           /
    o --- o --- o --- o --- o --- o

with 'o' revisions being trunk commits and local changes [1], [2] and
[3] forking from several different ancestor changesets, you can keep
your changes in a local branch like this

    o --- o --- o --- o --- o --- o --- [1] --- [2] --- [3]

Every time you "bzr pull" from the trunk, you can re-rebase your local
changesets on top of the new trunk.

Without rebase, you would have to merge each one of [1], [2] and [3]
separately, resulting in a final history similar to:

      [1] ----------------------------.
     /                                 \
    o --- o --- o --- o --- o --- o --- [m1] --- [m2] --- [m3]
                 \           \                  /         /
                  [2]         [3] ------------ / --------'
                    \                         /
                     `-----------------------'

with one merge changeset for each local patch.  This is a moderately
complex history graph, that is mostly readable for three local changes,
but things quickly get messy with, say, upwards of 20 local patches.

The mostly linear history of rebased changesets is easier to read for
local patches.  At least it is for me.

The good thing about keeping a local set of patches rebased to the
latest version of turnk is that you can start developing the patches
with revision N of the trunk:

    o --- o --- [N] --- [1] --- [2]

then you cal pull as many times as necessary from the trunk (pull
revisions marked with '*' below:

    o --- o --- [N] --- o --- * --- o --- o --- * --- [1] --- [2]

and keep the local patches rebased until they are 'done'.  When they are
ready for trunk, you can simply "bzr push" them and stop rebasing the
local patches.  They are not part of trunk and everyone will see them.

The down-sides of rebasing that I know of are:

  (1) You cannot publish the rebased changesets and then rebase them
      again.  People who pulled the `old' rebase will still have it in
      their local branch and you cannot do anything to delete *their*
      local changes.

  (2) Rebasing modifies the history but does not necessarily leave any
      trace of the old state of the branch.  So if you discover that you
      botched the rebase or one of the merges that happened *during* the
      rebase, you are screwed.  Keeping a backup copy of the local
      branch *before* a rebase operation (e.g. a tarball) is always a
      good idea.

  (3) Rebasing in a bound branch is probably a bad idea.  I am not sure
      how well the plugin will work with changes that are already pushed
      to the remote side of a bound branch.  It is very likely that it
      will create a very messed up branch state both in the local and
      the remote side of the world.

Having said that I've previously posted a, admittedly rather minimal,
example of instructions for the installation and the commands of the
bzr-rebase plugin at
<http://lists.gnu.org/archive/html/emacs-devel/2009-12/msg00871.html>.
It may be worth expanding on this if you think it would help you keep a
set of local-only patches until they are ready for the public trunk.

HTH,
Giorgos