[Monotone-devel] pluck problem

[Craig Lennox]

Greetings.  I'm a new arrival to the list, although I've been
following monotone's development since 0.16 or so.

I've been playing with 'mtn pluck' for a bit and in general I like it.
To me the name is not quite apt, because when you pluck something, it
no longer exists in the place you plucked it from.  I might have
called it something like 'mimic'.  Though that's probably not much
improvement in the stodginess department.  FWIW, arch's command to do
roughly the same thing (plus some metadata bookkeeping) is called
'replay'.

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.

Craig