RE: [stellation-res] Text merge test case: an analysis update

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Sun, 2002-10-27 at 21:47, Jonathan Gossage wrote:
> I think you will find that many programmers will have the folllowing
> perspective when dealing with simultaneous sets of changes by two
> developers. They will be unhappy with any algorithm that silently changes a
> modification made by the other developer. Unfortunately, every SCM I have
> seen does this all too often. In our shop we do not allow merges to happen
> because the results simply cannot be relied on. Fortunately, we only have 7
> developers so we can manage to keep from stepping on other peoples toes
> pretty much, but I agree that this practice does not scale well. The bottom
> line on this is that if we were to use Stellation in practice we would want
> to be able to prevent the need for merging which would imply some kind of
> artifact locking mechanism which is also undesirable. I think you may
> underestimate just how sensitive an issue merging is. Most people I have
> worked with are not prepared to tolerate a perceptable mis-merge rate.
> That's been my experience but I would be happy if you can show me where I am
> wrong.

I think the problem is, there are exactly two choices: either prevent
concurrent changes (ie, use locking), or allow concurrent changes and
deal with the problems of merge. Depending on the development process
used by a group, you need to choose which one to accept. 

Any group that realistically uses optimistic concurrency and merges on
large projects has to have a rigorous and careful process for validating
merge results. I've never seen a successful project that just merges
and doesn't check the results carefully. (If you look at the Eclipse
merge view during a synchronize, it's a nice aid for this: it lets you
look at the changes that make up a merge, and decide how to integrate
them.  Once you get used to it, it's quite nice.)

But personally, I'm honestly a fan of locking. I really believe that the
*main* reason that optimistic concurrency is so popular is because
people generally coordinate their work from outside the SCM system,
and aren't *really* making overlapping changes. Programmers A and B
may both be changing file f, but A is changing f.x, and B is changing
f.y, and the changes don't really overlap. Merge algorithms do a 
terrific job in this case. They do a much worse job when they try to
merge concurrent changes within a single method. (One thing that I'll
happily support when fine-grained gets working is to treat *any*
concurrent changes within a fine-grained unit as an automatic conflict.)

Really overlapping changes is a formula for disaster, and for real
overlapping changes, I don't believe it's really possible to do an
adequate job of automated merge. (One of my big worries about even
*trying* to be very smart about merges is that if the merge result is
too good, you'll get overconfident in the merge result, and won't check
it carefully enough.) I really think that true overlapping changes 
should *always* be treated as a conflict. But when you're working at
file granularity, where you don't know anything about the
semantic boundaries between elements in the file, you can't tell
which changes are really concurrent changes to the same element. So
you wind up back at the starting point: either ban all concurrent
changes to a file (file locking), or go the optimistic route and
check the merges.

My real preference is to allow better locks: locks of collections of
smaller units, rather than locks of source files. And when someone
chooses to break a lock, and make a concurrent change, the merge is
*their* responsibility. 

> Things that could go a long way to mitigate this would be support in
> Eclipse/Stellation using a visual display to allow interactive trial merge
> and correction of problem files. Even though I just ranted on, I do know
> that the problem files and situations are rare and a good toolset, including
> the ability to backup and re-merge using an interactive visual process would
> shut up all my objections.

I agree here. I think the visual merge support in Eclipse is a nice
start. Integrate it properly with personal branches, and you'll get
the ability to do trial merge, with the ability to back out.

> I do have some ideas on how to produce an algorithm that can do what I am
> after and I am about 75% through an initial impplementation. Anything new
> like this is going to require very thorough analysis before it can go into a
> production version. I do not think that you should even consider this until
> after we have the alpha release out the door.

If you have time, I'd really like to see a description of it. I
definitely don't want to try to really integrate it until after the
release, but I'm really interested in seeing the algorithm. (Also, if
your employer will support it, I think it would be an excellent thing to
write up and submit to the ICSE SCM workshop, which has a paper deadline
in December.)

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work Email: mcc@xxxxxxxxxxxxxx  ------- Personal Email: markcc@xxxxxxxxxxx