New design for a pre_commit hook

[James Westby]

Hi,

Aaron was asking about my revision properties hook today, and we
ended up discussing what a good hook would look like. Adding a
specific hook for adding revision properties seemed like overkill
if we could make a hook that allowed us to add revision properties,
and achieve other things.

There are some existing hooks that are close to what is needed, but
all of them have problems:

  * start_commit gets no information about the commit that is about
    to be performed, such as specific_files, and has limited ability
    to communicate information back to the commit, such as desired
    revision properties.

  * pre_commit is actually run after the revision has been committed
    by the builder, but before the branch tip is updated. It also
    has limited extensibility as the signature defines lots of
    parameters, rather than an object we can add things to later.

  * commit_message_template has the needed information, but can
    only communicate one thing back to the commit. It is also
    slightly special because of the way commit messages are handled.

We propose a new hook, with the following parameters:

  * tree - the working tree that is being committed, still locked.
  * revision - a Revision with as much filled in as possible by the time
               the hook is called.
  * callbacks to get:
    - The new inventory
    - An iter-changes-like between the basis tree and the tree that is
      about to be committed.

The revision the hook receives will have certain attributes that may
not be filled in, such as the revision id.

The hook can return a new revision if it likes, with changes from the
one that it receives that it would like to make. There will be certain
changes that are disallowed, such as changing the revision id, but you
would be able to set the message and the revision properties.

How does this look?

Thanks,

James