monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...)


From: Timothy Brownawell
Subject: Re: [Monotone-devel] Re: [cdv-devel] more merging stuff (bit long...)
Date: Sun, 07 Aug 2005 16:26:29 -0500

On Sun, 2005-08-07 at 01:06 -0700, Nathaniel Smith wrote:
> On Sat, Aug 06, 2005 at 02:05:43PM -0500, Timothy Brownawell wrote:
> > On Sat, 2005-08-06 at 02:08 -0700, Nathaniel Smith wrote:
> > >   1) whenever a user explicitly sets the value, they express a claim
> > >      that their setting is superior to the old setting
> > 
> > This claim is "in revision XXX, the value is set to 'a', overriding the
> > values set in revisions {YYY, ...}".
> 
> Sort of.  I think you have the right idea, but your description sounds
> more like a description of what was recorded, and here I want to talk
> about what the user's implied intentions are.  Merging is all about
> inferring intentions.

a   b
 \ /
  c*

In this case, c is superior to / overrides a and b.

a   b
 \ /
  a*

In this case, I would say that the new 'a' setting is meant to override
the 'b' setting, but not to replace/override the previous 'a' setting.

d   a   b
 \ / \ /
  a*  a*
   \ /
    a

With both marked 'a' settings not replacing the original 'a' setting
(but only the 'd' and 'b' settings), this wouldn't be a conflict. And I
wouldn't expect that a user would intend to get one here.


> > I think this could be solved by considering both 'b' revisions as one
> > entity, which overrides settings from parents of the first 'b' revision,
> > and also the 'a' revision (after the creation of the second 'b'
> > revision). pcdv would say that the second 'b' overrides the 'a'
> > revision, what about instead considering them as a single group that
> > overrides parents of any member, and all members of which are overridden
> > by any child that overrides one member? To handle the cases given as
> > "ambiguous clean", this scheme would have to allow a revision to belong
> > to multiple groups. A "group" would be a revision, and all descendents
> > that haven't changed names.
> 
> I'm afraid I'm really not following this.  What does "consider as one
> entity" mean, and "a single group", and so on?  Could you give some
> examples or something?


   Va
   / \
 Wb* Xc*
   \ / \
   Yc* Zd*

Revision Y is a child of revision X, and has the same value. If instead
of replacing the setting of that value in revision X or having Y
override revision W, X and Y were considered as one entity overriding
both the 'a' value from revision V and the 'b' value from revision W,
then this wouldn't be a conflict. Z overrides this entity because it
overrides X, so merging Z and Y would automatically have Z win, giving
'd' as the result.

In the case of 
a   a
 \ /
  a
, the descendent would be part of the group for the left parent, and
part of the group for the right parent.


    a
    |
    b
   / \
  c   b
  |  / \
  b  b  c
  \ /
   b

Here, the 'b' revisions have 2 groups (assuming no implicit undo). The
chain that the 'c' on the right branches from, and the 2 revisions
descended from the 'c' on the left. The 'b' at the bottom would be in
both groups. If there was implicit undo, then the second group of 'b'
revision would be noted as undoing a change away from the first group of
'b' revisions, so it would actually be the same group.

Tim






reply via email to

[Prev in Thread] Current Thread [Next in Thread]