Re: [Monotone-devel] Deterministic *-merge
On Fri, 2007-01-12 at 03:00 -0800, Nathaniel J. Smith wrote:
...
Deterministic merging
=
Beautiful! There's just one point I didn't follow, though.
But, magically, with deterministic *-merge, all orders work the same
-- it even turns out to be possible to merge two conflicts and get out
a non-conflict (!):
a a a
/ \ / \ / \
b* b*b* b*b* b*
/ \ / \ / \ / \ / \ / \
c* b c*c* b c*c* b c*
\ / / \ \ / \ / \ /
# / \ # # #
\ / \ / \ /
c c c
You lost me here. In the '#' node, you lost the specific values 'b' and
'c' - all you have is 'some unknown value'. How does merging two
'unknown values' produce a specific value?
I like the idea of not using the generic '#' and instead listing the set
of candidate values. This can be done in text files by some
not-so-pretty syntax tricks. Speaking of which, how did you envision
representing '#' in actual text files?
If the result of a conflict was replacing a scalar with a set of
conflicting values, we'd get a user action (creating a separate node)
that would pick one or replace the set by a new one. It seems like this
would be very useful when users need to resolve conflicts in practice...
At first I thought that was how you obtained 'c' above, but it turns out
not to be the case:
a a a
/ \ / \ / \
b* b*b* b*b* b*
/ \ / \ / \ / \ / \ / \
c* b c*c* b c*c* b c*
\ / / \ \ / \ / \ /
{b,c} / \ {b,c} {b,c}{b,c}
\ / \ / \ /
c c {b,c}
So I'm still stumped on how you obtained 'c' in all three cases. I must have
missed some important point here...
___
Monotone-devel mailing list
Monotone-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Deterministic *-merge
On 1/12/07, Nathaniel J. Smith [EMAIL PROTECTED] wrote: [snip] Example 2 (super bonus edition) === A more wacky example is: a / \ b* b* / \ / \ c* b c* Here we have two people who independently set the value to b, which then makes an accidental clean merge. Then two other people come along and independently overwrite the b's with c's. Because *-merge makes the decision to be conservative about implicit convergence, if either of the c's is merged with the b, it generates a conflict -- because someone made a decision to create the b in two different contexts, but the c came from someone overruling that decision in only one context: Forgive my possible ignorance, but if 2 people independently make the same changes to a revision and commit/push them on their own doesn't this end up being the same node in the graph? The way I understand it if 2 people make the same change simultaneously in 2 different databases then sync with each other that the only actual thing being synced would be an author cert on the revision, leaving you with 1 revision, not 2. Or am I misunderstanding the two people independently set the value to b remark above? According to my understanding this graph would just be: a | b | c since no merging of the 2 independent creations of b is necessary. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Deterministic *-merge
On 1/12/07, Justin Patrin [EMAIL PROTECTED] wrote: On 1/12/07, Nathaniel J. Smith [EMAIL PROTECTED] wrote: [snip] Example 2 (super bonus edition) === A more wacky example is: a / \ b* b* / \ / \ c* b c* Here we have two people who independently set the value to b, which then makes an accidental clean merge. Then two other people come along and independently overwrite the b's with c's. Because *-merge makes the decision to be conservative about implicit convergence, if either of the c's is merged with the b, it generates a conflict -- because someone made a decision to create the b in two different contexts, but the c came from someone overruling that decision in only one context: Forgive my possible ignorance, but if 2 people independently make the same changes to a revision and commit/push them on their own doesn't this end up being the same node in the graph? The way I understand it if 2 people make the same change simultaneously in 2 different databases then sync with each other that the only actual thing being synced would be an author cert on the revision, leaving you with 1 revision, not 2. Or am I misunderstanding the two people independently set the value to b remark above? According to my understanding this graph would just be: a | b | c since no merging of the 2 independent creations of b is necessary. I've just realized that what I'm saying here is monotone specific and that perhaps other revctrl systems which do not behave as monotone does would make these separate revisions, thus making this example useful. Let me know if I'm on the right track. -- Justin Patrin ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Deterministic *-merge
* Nathaniel J. Smith: This is where key idea 2 comes in again. Let's define an equivalence relation ~, as: for all x and y that are not equal to #, x ~ y iff x = y. for all x, # ~ x is always true. Or in words: every normal value is similar to itself, plus, # is similar to _everything_. All objects are equivalent if ~ is in fact an equivalence relation. But I don't think this is a problem. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Deterministic *-merge
On Fri, Jan 12, 2007 at 07:47:59PM +0100, Florian Weimer wrote: * Nathaniel J. Smith: This is where key idea 2 comes in again. Let's define an equivalence relation ~, as: for all x and y that are not equal to #, x ~ y iff x = y. for all x, # ~ x is always true. Or in words: every normal value is similar to itself, plus, # is similar to _everything_. All objects are equivalent if ~ is in fact an equivalence relation. But I don't think this is a problem. Err, right. Thanks, good point. What we want here is really a partial order relation anyway, as per the parenthetical paragraph of technicalness. So, uh, anyone who cares about such details should just ignore the thing about ~ and read the parenthetical paragraph. -- Nathaniel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
