Re: [Monotone-devel] pluck problem

[Nathaniel Smith]

On Fri, Jul 07, 2006 at 03:04:50PM -0400, Craig Lennox wrote:
> I have run into a small problem with pluck, however.  It is to do with
> an edge case that has always been present in monotone but which
> required deliberate malign intent to produce (so you expected what you
> got, and you got what you deserved).  With pluck, you can get there
> through mere carelessness.
> 
> If you have a revision 1234 which is the parent of revision 9876, and
> you are in a workspace whose base revision is 1234 (perhaps because
> your working branch includes 1234 but not 9876), and you blithely type
> 
>     % mtn pluck -r 9876
>     % mtn commit -m <msg>
> 
> You get:
> 
>     mtn: beginning commit on branch 'com.example.branch1'
>     mtn: warning: revision 9876 already in database
>     mtn: committed revision 9876
> 
> The result is that revision 9876 now has two Author, Date and
> Changelog certs, which monotone never expects to be the case and about
> which 'mtn db check' reliably complains.  I'm not certain what the
> lasting effects of this condition are (if any), but the only way I've
> found to fix it is to remove the offending certs by hand (hopefully
> before ever sync'ing to another database).
> 
> I can think of no good reason why monotone should ever allow a
> revision to be committed whose revision id matches one it already
> contains, so perhaps this warning ought to be upgraded to a 'misuse'
> failure to prevent this situation occurring in the field.

There is a very good reason to allow a revision to be committed that
matches an existing revision -- we have no way to prevent it.  In
general, when you want to know "Does revision X exist?", what you mean
is that you want to know if it exists "in the big repo in the sky",
not "in the partial information I happen to have on hand right now".
We could try to fake it by erroring out if the revision already exists
in _our_ db, but that doesn't prevent the situation from arising, just
makes it rarer and more mysterious when it does happen.

It can also already happen through perfectly non-malign means -- a
design goal, actually, was that if two people did the same merge,
they'd usually end up with the same revision, and if they did more
work based off of this merge then there would be no problem.  Another
example would be if a patch is sent to a mailing list, and two people
both commit it simultaneously.

I think a better solution would be to remove the warnings from 'db
check'.  They are sort of nice to have, but they keep scaring people
for no good reason.  We added this idea of "serious errors" to 'db
check' to try and make these not-really-errors-just-maybe-interesting
notes less scary, but it hasn't really worked.

-- Nathaniel

-- 
So let us espouse a less contested notion of truth and falsehood, even
if it is philosophically debatable (if we listen to philosophers, we
must debate everything, and there would be no end to the discussion).
  -- Serendipities, Umberto Eco