[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] pluck problem

From: Craig Lennox
Subject: Re: [Monotone-devel] pluck problem
Date: Tue, 11 Jul 2006 14:18:56 -0400 (EDT)

From: Nathaniel Smith <address@hidden>
Subject: Re: [Monotone-devel] pluck problem
Date: Fri, 7 Jul 2006 15:29:28 -0700

> On Fri, Jul 07, 2006 at 03:04:50PM -0400, Craig Lennox wrote:
> 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.

Thank you very much for the explanation.

In fact, the warning from 'db check' generally does NOT present
(contrary to my previous description) in cases where two people
independently commit the same change, because then the date and
changelog fields are likely to differ along with the author field.  It
does however arise with high certainty in the edge case when someone
commits a change then immediately plucks that change to a different
branch whose head revision happens to be the original change's parent

So, I agree this condition cannot be prevented, but it should be noted
in the command reference for the pluck command (whatever it ends up
being called).

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

Perhaps we could leave them in there, but require a switch like
--warnings (or --nitpick) to display them?  I agree they shouldn't
show up in normal usage (as they are quite often not errors serious or
otherwise), but it seems a pity to remove them altogether as they
could still be useful sometimes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]