Small hackish extension for Matt to use evolve with its current workflow

[Pierre-Yves David]

TL;DR mpm should use the `drop` command from `drophack` extension

I'm resuming my effort to have Matt Mackall using evolution instead of 
MQ for its daily review work. (last attempt was stopped by nasty bug in 
import --exact).

I'm making this discussion public because there will be useful insight 
on the current state of evolution (and aimed final behavior).

1. Summary of the current process
==================================
(probably simplified)


1. people patchbomb email to the mercurial-devel list
2. Matt takes the patches from its inbox and `qimport` it
3. Matt run some test on it
4. Matt may makes minor changes to the patch using MQ
5. Matt moves to the next patches (goto 2)
6. When Matt has enough patch he runs the whole test suite.

7.a If all test pass. Matt push it. (hg push)
7.b If some test fail. Matt drop it. (hg qdelete)
     (contributor will resend a fixed version)

8. contributor pull from main
9. contributor have to create obsolescence marker itself



2. Summary of step we aim at.
===============================
(Or at least my understanding of our current aiming)

1. people patchbomb email to the mercurial-devel list
2. Matt takes the patches from its inbox and `import` it
2.a if possible he runs `hg import --exact + hg rebase`
2.b Otherwise he runs `hg import` (and hope it applies)
4. Matt may makes minor changes to the patch using modern tool ;-)
5. Matt moves to the next patches (goto 2)
6. When Matt has enough patch he runs the whole test suite.

7.a If all test pass. Matt push it. (hg push)
7.b If some test fail. Matt drop it. (hg <something>)
     (contributor will resend a fixed version)

8. contributor pull from main
(no more 9. yeah)


3. Current issue with the new way
==================================

* The script doing Step 2.b will have to create an obsolescence
   marker between the node recorded in the patch header and one created
   on import

* 7.b introduce a major concern: step 2 have likely created an
   obsolescence marker from the original node to something else in
   Matt repo. If Matt push the markers without the changeset this will
   make the original changeset disappear from the contributor repo.
   that would be -bad-.
   With the current strategy planned for evolution we should not send
   markers relevant to a changeset without the changeset. Unfortunately
   it is not implemented yet (and we currently send every marker on each
   push). Another bad new is that the current plan include sending
   `prune marker` when sending the parent of the pruned changeset. That
   rules out using `hg prune` as is for dropping patches.

* One minor issue is that 2.b may create obsolescence cycle if we are
   unlucky

* A second minor issue is that --exact it currently broken if the
   original node had anything in extra. This will eventually get fixed.

4. Current solution for dropping
==================================

I've added a small "drophack" extension to the mutable-history repo. 
This extension adds a "drop" command that push a changeset, all its 
ancestors and -all-associated-markers-. This should cover the current 
need for the early day.

Other people should not considering using it nor including them in there 
official work flow.

-- 
Pierre-Yves David