Re: [Gnu-arch-users] Star merging with 3 branches

[Andrew Suffield]

On Tue, Dec 09, 2003 at 05:22:48PM -0800, Tom Lord wrote:
>     > From: Joshua Haberman <address@hidden>
> 
>     > From the way you describe it, it sounds like the problem [of
>     > random-topology merging] could be completely avoided by adopting
>     > a discipline of never making any manual changes when committing
>     > a merge; any desired changes to the merged changes should be
>     > committed as a separate changeset.  This does not remove any
>     > expressive capability from arch, it just requires merges to be
>     > broken into two steps.
> 
> That's correct.   The devil is in the details, however.
> 
> In the general case, merges can have conflicts and, absent "new
> mechanisms", you shouldn't commit while conflicts persist.   Resolving
> conflicts runs against the discipline you are suggesting.
> 
> Rob Collins has been exploring and using a tool that, as I understand
> it, just ignores that issue -- perhaps he can speak about that.   I'm
> not sure whether his approach is simply to "not permit conflictful
> merges" or "trust the user that the resolution of conflicts doesn't
> _really_ count as a change".

Close, but not quite. The principle behind pure merges is that they
are sufficient to represent *any* possible change, by
aggregation. Conflicts aren't allowed because you can patch them out
of existence, and that's much easier to handle when merging than a
mixed changeset.

Here's an example of what you put in the archive when you have to
resolve conflicts. Generating these changesets isn't entirely trivial,
but it turns out that it isn't all that hard either.

Let there be a revision R1, which we have in a project tree.

Let there be a changeset C1 which conflicts when applied to R1.

We changeset C1 to R1, which generates conflicts. We then resolve
these conflicts manually.

We want to commit this as R2, succeeding R1. Furthermore, we want to
include C1 as a pure changeset. So, we want this:

  R1 ------> R2
       C1

That isn't valid at present, so we stuff another revision in between:

  R1 ------> R2pre ------> R2
       C2            C1

You can compute C2 by building the relevant trees and diffing; in tla,
take the project tree for R2, 'do-changeset --reverse C1', and then
'undo --output C2'.

This is actually incomplete. It might not be possible to generate R2
from C1 directly; the contents of R2 might not match one or more "new"
hunks in C1. In general, we want this:

  R1 ------> R2pre ------> R2mid ------> R2
       C2            C1            C3

Computing C2 and C3 here is a little harder. You can do it,
inefficiently, by grabbing the revision that originally corresponded
to C1 (from a different branch), and using it as R2mid, then
proceeding to diff/undo the various trees to work out the
changesets. Alternatively you can compute it directly; this requires
some diff-munging code, but it's fairly simple - there's an infinite
number of valid (C2,C3,R2pre,R2mid) tuples and you can pick any of
them. The easy one is "Find every conflict between reverse-C1 and R2
and generate the diff that goes between them; let C3 be the sum of
these diffs". From that you can compute R2mid, and then you can
proceed as before to compute C2. I don't know if that's the *best*
choice.

Now, having done that, I suspect that --skip-present is no longer
quite the right behaviour. If you skip C1, you probably want to skip
C2 and C3 as well, even if they aren't already present (this has been
the source of much speculation about possible 'groups of changesets'
support in arch, nothing useful yet). But practical investigation is
needed here; I've reached the limit of what I can reasonably imagine
without trying it.

Unfortunately, the current "implementation" of pure-merge is somewhat
proof-of-concept in nature, and doesn't implement any of this stuff.

[Hey, did anybody ever actually write this stuff up properly? We
hashed it out on IRC, months ago, over the course of a couple of
evenings, but the "How to handle conflicts" stuff seems to have been
forgotten]

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'                          |
   `-             -><-          |

signature.asc
Description: Digital signature