Re: [Gnu-arch-users] Re: microbranches: prism-merge vs multi-merge

[David Allouche]

On Mon, Jun 07, 2004 at 11:07:59AM -0400, Aaron Bentley wrote:
> Julian T. J. Midgley wrote:
> >In article <address@hidden>,
> >Miles Bader  <address@hidden> wrote:
> >
> >>The `obvious' way would be to re-tag from the upstream branch...
> >
> >
> >Or to have a tool for forking a new set of microbranches from the
> >latest revision of the devel branch (after the upstream merge) and
> >replay or star-merge the changes from the old microbranches into the
> >new ones.
> 
> I've added a "rebase" command to aba that does this.  (at least, it does 
> it 'retail'-- you have to invoke it once for each branch that you want 
> to change the basis of.)
> 
> This is one case where mixed versions would be quite handy though.  That 
> would avoid the branch proliferation problem, and if we could rebase 
> without branch proliferation, we might not need need submit branches.

Hmm... just thinking about it...

Up to know, I settled with the idea that the relevant information with
a microbranch was its delta w.r.t. its parent branch, I thought the
process ought to look like:

  1. Tag from parent

  2. One or more new revisions in the microbranch

     (so far all things are clean and simple)

  3. The parent is updated, the microbranch was not merged, and
     conflicts arise.  The microbranch needs to be updated. If we want
     information to stays neatly organized, the conflicts must be
     resolved in the microbranch.

     The way to do it clearly is to merge upstream changes into the
     microbranch, but then the relevant information is no longer the
     patches in the microbranch. Then what is it? It's the delta
     relative to the main branch

That process overlooked the fact that it dropped the promise of
"microbranches being cheap", because the amount of data in a microbranch
is going to grow linearly with the amount of (new, relative to branch
point) data in the parent branch. That is Bad. 

The amount of data in a microbranch must only grow linearly with the
amont of work put into maintaining the branch. I do not know how the
"continuation commit" worked with larch, but let me think this through.

Currently, the "cheap microbranches" promise can be held be using mixed
versions. The process would be:

  1. Tag from parent (base-0)
  
  2. One or more new revisions in the microbranch, up to patch-N
  
  3. Tag from updated parent (patch-N+1)
  
  4. Merge in one of two ways:
  
     a. Give priority to microbranch changes.

        i. Undo to N-1 (before new continuation).

        ii. apply-delta(parent(base-0), parent(patch-N+1))

        iii. Restore the patch-log for patch-N

     b. Give priority to upstream changes

        i. apply-delta(patch-1, patch-N)

  5. Fix conflicts and commit.


Except for the in-version continuation revisions, that is just clean.
The problem with that approach is that, for long-lived branches, the
fraction of uninteresting revisions (that is, tags) is going to grow
asymptotically up to half the number of total revisions... That has a
definite feeling of "working around the missing feature".

So, maybe we need "commit --continuation" (or some other option name, I
do not remember off-hand). This would create a continuation revision
with an associated changeset. The changeset would be the difference
between the continuation parent and the commited tree. The process would
then look like:

  1. Tag from parent (base-0)

  2. One or more new revisions in the microbranch, up to patch-N

  3. Merge with updated parent, on one of two ways:

     a. Give priority to microbranch changes: star-merge UPSTREAM

     b. Give priority to upstream changes.

        i. Undo to base-0 (last continuation).
        
        ii. update or star-merge UPSTREAM (no conflicts)

        iii. update or star-merge TREE-VERSION
        
  4. Fix conflicts and commit as a continuation of the last UPSTREAM
  revision for which we have a patch-log.

That is much simpler! And the data stored in the microbranch version
going to be exactly what it is meant to be: the history of the patch!

My conclusions:
  
  -- tag-in-version are still not really useful for common usage, but
     they can be useful as a temporary workaround until "commit
     --continuation" is restored

  -- tag-in-version are simple cases of continuation changesets, if the
     various merge tools are fixed to behave sanely in the face of
     continuation changesets, then they will also behave sanely in the
     face of tag-in-versions

Bugs should be fixed.

-- 
                                                            -- ddaa