Re: [Monotone-devel] Lack of conflicts checking

[Ethan Blanton]

Nathaniel Smith spake unto us the following wisdom:
> On Tue, Aug 07, 2007 at 10:19:49PM -0400, Ethan Blanton wrote:
> > So, not to throw a wrench into the mix, here ... but die-die-die has
> > come up quite a few times in Pidgin development, and we've already had
> > to work around it a few times.  (Specifically, we cannot fork out
> > several of the libraries in our tree and still propagate changes back
> > to Pidgin, with die-die-die.  Ideally we would like to branch
> > im.pidgin.pidgin to im.pidgin.somelib, pivot_root somelib to the root,
> > and drop everything else, then be able to merge changes back and forth
> > across the divide.) 
> 
> Killing die-die-die won't help here; what you want will never work,
> because of what merging fundamentally is.  In particular, the part
> where it is commutative.

Right, I understand this; there needs to be a way to mark one branch
or the other as deviant with respect to this policy.  Perhaps modules
are the right answer to this (as you suggest further down), but I
don't think so.  Consider that the library which is broken out would
have auto* junk in it which is not necessary in the embedded version,
for example -- again, a case of adds/drops which one does not want to
propagate back and forth.

Maybe what I'm asking for is just too complicated, but as it stands,
we can't even achieve a *weakened* scenario of this which would be at
least moderately useful.  That is, pulling the library out as a
one-time thing, then restricting all future merges to be from the
external library to the embedded version.

[snip]

> > Unfortunately, I'm not convinced that content
> > conflicts are always sufficient; for example, suppose I have a
> > function foo() defined in foo.c, which is used in several places in my
> > codebase.  I subsequently create a branch, and proceed to eliminate
> > all usage of foo() on the trunk.  I notice that it is unused, and drop
> > the file -- with no changes to foo.c.  On the branch, I add a few
> > places where foo() is called, and therefore do not drop the file, but
> > do not change it.  When I merge, I want to *keep* foo.c, even though
> > it has never changed, due to undetectable (to monotone) semantic-level
> > dependencies.
> 
> Of course content conflicts are not always reliable, in the sense of
> catching everything; they're not supposed to be.  They're supposed to
> be predictable, so that it's obvious to a human *when* they will be
> reliable, and when they won't.  They should also be reliable enough
> that their existence saves work (as compared to merging everything by
> hand), but that's secondary.

Predictable is great, but not sufficient in this case, I don't think.
I think I'm simply coming back around to needing workspace merges to
achieve what *I* consider consistent merge behavior.  ;-)  Automatic
flagging of change/drop as a conflict seems like a no-brainer good
idea; extending that to automatic resurrection in favor of the change
would just be frustrating, I think (because semantically-required
resurrection cannot be inferred by monotone, and would require an
additional follow-on revision to achieve semantic consistency).

I think I'm more fixated on semantic consistency than monotone, is,
which leads me to a number of impedence mismatches.  This might be
another one, so I'll let it lie.  ;-)

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
                -- Cesare Beccaria, "On Crimes and Punishments", 1764

signature.asc
Description: Digital signature