[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [stellation-res] Merge Issues
|
On Mar 8, 2004, at 4:54 PM, Jim Wright - IBM Research wrote:
I've been working to integrate the new T-Client GUI with the existing
core
engine merge facilities. JUnit testing during this work has revealed a
number of flaws in the existing compound merge algorithm
(CompoundArtifactAgent.merge).
Rather than fix the code piecemeal, I am re-analyzing the
requirements, and
will then redesign/reimplement the algorithm.
I would appreciate some help from Mark and anyone else with
merge-related expertise.
Please hold off on doing anything with this... I think it's worth
taking the
time to do a bit of formal modelling in order to guarantee that all of
the
cases can be handled correctly. I'll work up a model in Alloy, and post
it as it progresses. Once the cases are all correctly identified,
writing the
code should be a breeze.
-Mark
I've set up a Wiki page to discuss these issues:
http://stellation.eclipse.org/twiki/bin/view/Stellation/MergeIssues
It currently contains my working notes (sorry if they're scattered and
hard
to follow; at least they're better than my handwriting!)
Here is a summary of several of the key issues:
A) The content of a CompoundArtifact is a set of <name,ID> member
bindings.
Both the ids *and* the names must be considered during a merge. (It's
entirely possible that an artifact has been renamed but not otherwise
changed, or has been moved to a different parent within a particular
image,
or has been changed, renamed and moved all at once, etc.)
B) Compound merges involve several semi-independent factors. Several
combinations of these factors are not handled correctly; others are not
handled at all.
Up to three images are involved in merges: a leaf image (source of
changes),
a base or target image, and a common ancestor image. A given
CompoundArtifact may be present in one, two or all three of these
images.
Where present, that CompoundArtifact may contain different member
bindings
for a given artifact.
There are a number of possible combinations that must be taken into
account
both to merge content (when that can be done automatically) and to
create an
appropriate, accurate conflict indication when manual intervention is
needed.
C) Additional information about the complete parentage of an artifact
within a given BranchImage is needed in order to handle certain types
of
merge conflicts. It is not always sufficient to know the immediate
parent
(CA containing a given member binding). It is sometimes necessary to
know
the complete chain of parents (up to the root CA of the image). This
information is useful both when generating merge conflict indications
Comments and suggestions ?
Further discussion should probably take place on the Wiki, but
comments on this list are welcome as well.
- Jim
--
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
_______________________________________________
stellation-res mailing list
stellation-res@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/stellation-res
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM Research
*** http://stellation.eclipse.org
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxx
