[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Lack of conflicts checking
From: |
Ethan Blanton |
Subject: |
Re: [Monotone-devel] Lack of conflicts checking |
Date: |
Wed, 8 Aug 2007 12:15:09 -0400 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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