Re: [Monotone-devel] 2 explicit merges which are the same, apart from destination branch => invariant violation

[Daniel Carosone]

On Mon, Jun 05, 2006 at 02:19:00PM +0200, Marcel van der Boom wrote:
> True, and doing this manually gives (me) a sufficient hint to do it  
> manually, after the error. It becomes more hairy when this runs from  
> a script.
> 
> >Leaving aside the error handling, there's no need to do the merge
> >twice - all you need to do is give the first merge result the two
> >branch certs, one in the merge and the other with an approve right
> >after.
> True, but why? mtn can do that for me, or tell me to do it. It doesnt  
> have to error out with a 'this is a bug' kinda thing, no?

As I said, "leaving aside the error handling".. :-) My suggestions
were aimed at getting you to your stated goals with the tools at hand
today. If you didn't really need those hints, great, and we can move
on to the error handling discussion.

Clearly there is a user interface issue here in the way the error is
detected and reported which could be more helpful or less panicky, and
monotone could perhaps be smarter in how it responds to some
situations.

I presume this test is a guard against, among other things, the very
faint possibility of a hash collision creating two revisions with the
same id but which aren't really identical.  It may also be a guard
against some other kinds of esoteric bugs in the code, not necessarily
any specific or anticipated problem. Monotone is full of careful
checking against internal consistency failures like this.

Now that you've found it can be exposed to the user in this
obvious-in-hindsight way, it's not the right guard to catch usage
mistakes, let alone try to intuit around them and turn the requested
action into something else.  But getting such things right can be
tricky, even once you know you need them.

For example, you might first consider a check before even trying to
create the merge to see whether the nominated ancestors already have a
merged descendant - but this would prevent someone re-doing a manually
assisted merge to produce a different child. You might decide to just
print a warning there, and/or set a flag that causes some more helpful
message to be emitted instead of the 'almost certainly a bug' message
if the merge comes out the same anyway.  Or you might even just ignore
the error and proceed to add certs to the existing revision, but
perhaps hide a future internal bug or a bug in an external frontend.

If, as you say, you're running monotone from a script, it's unclear to
me whether trying to recreate the same merge indicates a problem in
the script monotone could help flag, or a detail it could help hide
for convenience.

--
Dan.

pgplGahjgLyRl.pgp
Description: PGP signature