"Chris Foote" <Chris.Foote@xtra.co.nz> writes:
> Additionally the Clearcase merge command uses combined deltas when doing
> Given the Base revision (B) and additional contributors (C1, C2, ... Cn).
> / | \
> 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)
Let me check I understand this diagram. You have a base revision B and
several modifications C1, C2, .. Cn. The "merge result" is obtained
after merging all of C1, C2, ..Cn back into one B, creating Bn say,
Now you can commit after each merge, or you can carry out a series of
merges and commit once after all of them. Which you do doesn't really
affect the merge procedure, it only affects the number of revisons
that get created between B and Bn.
> 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
Not sure. In the end you have to deal with conflicts. The only
practical way I know to do that is to generate three fulltexts and run
a three-way diff, the conflicts are then in a human readable form. Now
the delta-combiner may be used during the fulltext generation, but
that is a detail hidden from the merge algorithm. Or are you propsing
that we attempt to merge at the vdelta level? I guess that might be
possible (I don't know enough about vdelta to say) but I don't know
whether it's desirable. How would it cope with conflicts? Perhaps we
can do a vdelta merge and fallback to fulltexts if there is a
Using fulltexts, the C1->B merge does a three-way diff between B, C1
and WC (the working copy, which might be plain B). You can commit at
this stage and generate B1, then the C2->B1 merge is a three-way diff
between C2, B and WC (which may be plain B1). Or you may choose not
to commit after the first merge, in which case the C2->B merge is
still a three-way diff between C2, B and WC.
As far as removing deltas goes (sometimes know as a "subtractive
merge") it's much the same as an ordinary merge. It's a three-way
diff, with the common file chosen to get an appropriate reverse
diff. The only tricky bit is choosing the format for storing the merge
meta-data. It is possible to get conflicts during a subtractive merge.
One related point: thus far, I have been assuming the merge gets
written into a working copy. I suppose the merge could get committed
straight into the repository if there are no merge conflicts. I can't
imagine ever wanting to do this with code I was developing, but I can
see that it would be possible for Subversion to do it.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:37:06 2006