Re: [Monotone-devel] Lack of conflicts checking

[Nathaniel Smith]

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.

I.e., say we had resurrection, and you created a branch by
pivot-rooting and then dropping extraneous stuff.  When you merged
back to trunk, that would cleanly merge to killing off everything but
that lib, okay, no problem, we can resurrect it.  But now when you
merge from trunk to the branch, that will cleanly merge to
resurrecting everything again... (and probably at inconvenient
locations).  Okay, we can kill it again... but now there's a kill in
history that beats that resurrection, so when you merge back to trunk
everything cleanly dies again...  For what you want to work, merging
two trees would need to give different results depending on whether
you were planning to deposit the result into mainline or the branch,
i.e., which direction you were merging.

You want something like the modules that have been discussed on list
recently (e.g. see Graydon's recent post).

> 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.

Question at hand is whether we would hit a sweeter spot on that
predictability/usefulness trade-off if we made content edits conflict
with file deletes.

-- Nathaniel

-- 
- Don't let your informants burn anything.
- Don't grow old.
- Be good grad students.
  -- advice of Murray B. Emeneau on the occasion of his 100th birthday