Transaction semantics for transplant and import

[Greg Ward]

Hi folks --

my recent work on rollback has me thinking about import and
transplant. Specifically, both currently just piggyback on commit's
transaction semantics, so if you you use import/transplant to create
multiple changesets, rollback only destroys the last one. And it says
"undo commit" rather than "undo import" or "undo transplant".

This could be particularly annoying with "hg import --bypass", which
doesn't update to the new tip:

  $ hg vers -q
  Mercurial Distributed SCM (version 1.9.2+104-59e8bc22506e)
  $ hg export 607 | hg import --bypass -
  applying patch from stdin
  $ hg rollback
  abort: rollback of last commit while not checked out may lose data
(use -f to force)

That's annoying: imports are not valuable like commits are. We should
feel free to destroy that changeset without --force.

So my plan is to see if I can make 'import' create its own transaction
around the entire sequence of imports. This is a behaviour change, but
IMHO a good one: it means that rollback after importing multiple
changesets would rollback the entire "hg import" command, not just the
last bit. And it also means you would not have to "rollback -f" after
"import --bypass"

Please let me know if you think this is a bad idea.

Greg