merge with stable

prune: update to successor rather than parent when prune '.'

import: --obsolete flag for automatic obsolescence marker creation A new `--obsolete` flag is added to import. When present, the new node will be marked as a successors of the one specified in the `Node` field of the imported patch. No marker are created when revision have the node expected in the patch. This improves email based work flow where implicit rebase are likely to happen and extra information are lost, changing the hash. This new behavior requires a flags, otherwise the `hg export x | hg import -` idiom would change, turning the source obsolete. (Changing from `hg graft x` to `hg rebase --dest . --rev x`) This change only takes effect when using Mercurial 3.0 and above

merge with all other change to 3.3

update 3.3.0 readme to include minimal mercurial requirement This clarify the situation.

evolve: fix grammar in a comment

README: document how to run the tests

uncommit: change 'kill' to 'prune' in error message 'kill' was renamed to 'prune' Long time ago.

readme: the forgotten update strike again

evolve: protect call to rebase within a wlock (#42, #35, #16) Without a wlock, repo.commit would blow away the dirstate's parents on OSes that have no 'os.symlink' support in python, leading evolve to produce a merge instead of a rebase. If a user ran the rebase command instead of evolve, then things would work because rebase is wrapped in a giant wlock. Unfortunately, we can't use the same idea of wrapping the evolve command in one giant wlock because that's too early in the process. If the lock did wrap the entire evolve command, then the working directory would save its current parents which, since rebase hasn't been called yet, would be just p1. Therefore, we need to obtain the lock *after* the dirstate's parents are changed but *before* the call to rebase. This way ensures that when a conflict happens the working directory correctly shows both parent changeset.