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

["Jonathan Gossage" <jonathan@xxxxxxxxxxxxxx>]

----- Original Message -----
From: "Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>
To: <stellation-res@xxxxxxxxxxxxxxx>
Sent: Tuesday, October 29, 2002 9:01 AM
Subject: RE: [stellation-res] Text merge test case: an analysis update


> 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.

You will get no argument from me on this one. I also think this is the way
to go.

>
> > 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.)

I need to get it working and tested out before anything else. I find that I
need to write code to do even conceptual design. I find it much easier to
work out all the requirements for edge conditions etc. by writing the code.
Once this is done I can then produce a verbal description.

BTW what is the involvement needed from my employer goven that I already
have full clearance to work on Stellation?
>
> -Mark
>

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx