Re: Zack's list of requirements

[Zack Weinberg <zack at codesourcery dot com>]

Mike Stump <mrs@apple.com> writes:

> On Monday, December 9, 2002, at 02:20 AM, Tom Lord wrote:
>> 2f. Perform conflict resolution by automatic formation of
>>     microbranches.
>>
>> Intriguing, but I don't completely understand what you want.
>
> I don't know if what I want it related to what Zack mentioned above,
> but what I want is an ability to handle this problem:
>
[snip example]
>
> The idea is to reduce the work the user has to do to resolve
> conflicts. Zack, is this close to what you want?  If not, I'd like to
> hear some more details...

I do not know how close what I have in mind is to what you have in
mind.  I'll describe the feature I have in mind in some more detail,
and y'all can tell me what you think.

(I'm holding off responding to the big long messages because it'll
take a while to do and I have work to get done.  I'll get to them
... probably tonight.)

Conflict resolution by microbranches goes like this.  We start with
some base revision of a file.  Let's say Mel was the last person to
check something in there.

  -- ... -- [MEL] 

Two other developers, let's call them Dave and Helen, both check out
the tree and start hacking.  They make changes to the same file.
Doesn't matter if they conflict (in the CVS sense) or not.  Now they
both try to check their changes in.  CVS says somebody loses the race
and has to update, then check in a merged version.  This is wrong.  It
loses information.  What should happen is, both checkins should
succeed, creating two sibling revisions:

 -- ... -- [MEL] --- [DAVE]
                 \-- [HELEN]

Dave won the race so his checkin gets to be HEAD.  Helen's checkin
succeeds but it's pushed onto a branch.  It is now her responsibility
to perform the merge, which gets checked in as a *separate* revision:

 -- ... -- [MEL] --- [DAVE]  --- [HELEN+DAVE]
                 \-- [HELEN] --/

Of course, someone else, let's call him Artie, could have been a busy
beaver and checked in something on top of Dave's change by the time
Helen gets round to checking in her merge; then the same thing happens
again:

 -- ... -- [MEL] --- [DAVE]  --- [ARTIE]
                 \            \
                  \- [HELEN] --- [HELEN+DAVE]

And then she does another merge and finally gets to win the race. Yay.

 -- ... -- [MEL] --- [DAVE]  --- [ARTIE]      --- [HELEN+DAVE+ARTIE]
                 \            \                 /
                  \- [HELEN] --- [HELEN+DAVE] -/

Of course this process *really* applies at change set boundaries, not
file boundaries; so if even one file conflicts between two change
sets, one entire change set gets microbranched.

What's the point? you may be wondering.  First, it's always possible
to recover the exact bits that the original developer tested.  GCC has
a perennial problem where someone tests the source tree at point A,
then tests A + their changes, then does an update to point B plus
their changes, then commits, but something in the delta between A and
B breaks in interaction with their changes -- and what they tested,
[A+changes], is forever lost.

Not only is it possible to recover what was tested, but it's possible
to promote any of the above set of deltas to tip-of-trunk.  Suppose
Mel comes back and discovers that what Dave did is fine, and what
Helen did is fine, but what Artie did is broken -- she can just tell
the system "make [HELEN+DAVE] tip of trunk" and boom, the broken
changes are on a branch; other people can move forward.  Artie can fix
his bugs later.  (In other words, backing out changes is really easy,
and putting them in again once they're fixed is also easy.)

And finally, because all of the merge participants are present and
recorded in the version history, it's possible to use a smarter
algorithm to execute the merges than would be available with CVS's
semantics.  This is where your example fits in, Mike.

zw