Re: "svn diff" and "svn merge" sittin' in a tree

Additionally the Clearcase merge command uses combined deltas when doing
merges.

Given the Base revision (B) and additional contributors (C1, C2, ... Cn).
i.e.
          --------B--------
        / | \
  d(B,C1) d(B,C2) d(B,Cn)
      / | \
    C1 C2 . . . Cn

Then the merge result is B + d(B,C1) + d(B,C2) + . . . + d(B, Cn)

By using this Clearcase lets you merge any revision delta ( or range of
deltas) to
any other branch. You can also remove any delta(s) you wish.

I am wrong in thinking that this is another application for the delta
combiner?

--
Chris
----- Original Message -----
From: "Philip Martin" <philip@codematters.co.uk>
To: <dev@subversion.tigris.org>
Sent: Sunday, February 10, 2002 3:07 AM
Subject: Re: "svn diff" and "svn merge" sittin' in a tree
> A few thoughts about merging, I haven't tried to articulate these in
> the context of Subversion before, so bear with me.  If nothing else,
> it will ensure I'm talking about the same things that you are :)
>
> It really only makes sense to merge things that have a common ancestor
> (thus the need for three files as you pointed out), so consider two
> files foo.c and bar.c with a common ancestor
>
>
>    foo.c:N-1 --- foo.c:N --- foo.c:N+1 ..... foo.c:X
>                   \
>                    bar.c:M --- bar.c:M+1 ..... bar.c:Y
>
> Now foo.c:N and bar.c:M are identical, and either can be considered
> the common ancestor. Next consider a merge, lets assume that the
> working copy contains foo.c:X and we want to merge bar.c:Y into the
> working copy. Thus we need the diff between bar.c:M and bar.c:Y which
> we apply to foo.c:X. This is just like applying the diff
>
>       svn diff -rM:Y bar.c
>
> to foo.c. The diff editor will generate the two fulltexts for bar.c
> and the full text for foo.c exists in the working copy. This looks OK,
> we can see that it should be easy to extend the diff editor to do
> this. In the above command, bar.c could be a working copy path or an
> URL.
>
> However, in my experience, merging individual files is not the common
> operation, most of the merges I do involve directory hierarchies. This
> still looks OK, the diff editor already handles directory hierarchies.
>
> Now I understand that Subversion intends to store merge information in
> the metadata. This is good because merging often happens multiple
> times. So after the above merge, development continues and later I
> want to merge again
>
>    foo.c:N-1 --- foo.c:N ........ foo.c:X ...... foo.c:X+A
>                   \                ^
>                    \               | merged
>                     \              |
>                      bar.c:M ..... bar.c:Y ..... bar.c:Y+B
>
> When we come to merge foo.c:X+A and bar.c:Y+B we don't really want to
> use the common ancestor N/M, rather we want to use X/Y the most recent
> merge. Again this is just like applying the diff
>
>       svn diff -rY:Y+B bar.c
>
> to foo.c. Still everything looks OK, the diff editor can do this sort
> of thing. At some point the metadata has to be interrogated to obtain
> the common ancestor, but the basic operation is the same.
>
> However, a problem occurs when we consider merging a complete
> hierarchy. In this case the most recently merged revision may not be
> the same for all the elements in the hierarchy. Individual files, or
> subtrees, of the hierarchy may have been merged at different
> revisions. It is not so clear (to me anyway) that the diff editor can
> easily be modified to handle this.
>
> Using previous merge information is important if we are to have an
> effective merging algorithm. If the previous merge is ignored, the M-Y
> changes will be applied a second time. With luck this will just result
> in an "already applied" message, the bigger problem is if the X/Y
> merge resulted in conflicts that needed to be resloved. If the X+A/Y+B
> merge can use X/Y as a common ancestor these conflicts will not occur
> again. However if the previous merge is ignored, and N/M is used as
> the common ancestor, the conflict will reappear.
>
> Let me explain how ClearCase handles this problem. ClearCase also
> stores merge information in metadata and uses it to improve multiple
> merges. The basic ClearCase merge command merges a file or directory,
> but it is not recursive. It only affects a singe file, or a single
> directory without its files. The merge command is coupled with the
> findmerge command which *is* recursive. Running a findmerge will
> search the heirarchy[1] and identify the individual elements that need
> to be merged. The user will generally invoke a findmerge command to
> merge two branches, automatically running a number of merge commands
> on individual elements.
>
> Subversion may well need to adopt a similar approach. It may require
> some sort of merge editor that identifes the common ancestor for each
> element. This in turn might invoke a modified diff editor to carry out
> each individual merge, or it may just carry out the merge itself.
>
> The other solution is to do what is normal practice in CVS (at least I
> think it is normal practice, I'm not a big CVS user.) That is to
> manually tag (copy in Subversion terms) before (and after?) each
> merge. Then you can refer to the tags in subsequent merges, thus
> providing the common ancestor manually.  I would *really* like
> Subversion to do better than this.
>
> A point of reference: the ClearCase merge metadata (sometimes referred
> to as "merge arrows") and the actual merges are distinct. The default
> behaviour of the findmerge/merge commands is to record the merges in
> the metadata, but ClearCase does allow merges without recording
> metadata, and it also allows the generation of the metadata without
> carrying out a merge. I have never used either of these features.
>
> Finally, the ClearCase findmerge command allows a merge conflict
> resolution application to be started automatically to resolve each
> merge conflict as the merge progresses. The GUI version of this
> application is rather neat (even to this command line fan) and using
> this feature means that when the findmerge completes all conflicts
> have been resolved. Much as I liked this, I would rate it lower than
> the proper recording and use of merge metadata.
>
> [1] Running findmerge on a large hierarchy can be expensive - minutes
> even hours rather than seconds. The findmerge command is so
> powerful/complex that it provides a "dummy run" option that just
> reports what would be merged, rather than actually carrying out the
> merge.
>
> --
> Philip
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org