pre-commit check hook

[Martin Pool]

It would be nice if a hook could get the chance to examine the to-be-committed tree and eg run 'make check'. This would catch things like simply broken revisions, inconsistent selective commits, files that are needed but not added, and things that don't work in a clean rebuild.

* Pre-commit check. If this hook is defined, it needs to be handled
  specially: create a temporary directory containing the tree as it
  will be after the commit. This means excluding any ignored/unknown
  files, and respecting selective commits. Run the pre-commit check
  (e.g. compile and run test suite) in there.

  Possibly this should be done by splitting the commit function into
  several parts (under a single interface). It is already rather
  large. Decomposition:

   - find tree modifications and prepare in-memory inventory

   - export that inventory to a temporary directory

   - run the test in that temporary directory

   - if that succeeded, continue to actually finish the commit

  What should be done with the text of modified files while this is
  underway? I don't think we want to count on holding them in memory
  and we can't trust the working files to stay in one place so I
  suppose we need to move them into the text store, or otherwise into
  a temporary directory.

  If the commit does not actually complete, we would rather the
  content was not left behind in the stores.

[John A Meinel (jameinel)]

I would say that step 1 is to have a "pre-commit" hook as part of the Branch.hooks. Which will be called after we have figured out everything that we need, but before the Branch.last_revision() has been updated.
This ensures that you have a stable view of the tree.

What would also be nice is if the pre-commit hook takes the list of changes that commit worked out. This way, if you want to do something like "do all modified files have only spaces and no tabs", you can do that without having to look at the full tree. (Also works for checking line endings, etc)

At that point, the plugin/hook itself can decide whether it wants to build a complete tree in a temporary area, and run something like 'make check' there.
I would make sure we have enough helpers to make that easy for a plugin (something like bzrlib.transform.build_tree). But I wouldn't expect the pre-commit hook to do it by itself.

Though, I could also see if you had multiple pre-commit hooks that wanted to work on a pristine tree, then you would want a way they could share it, so you don't have problems.

Note, that if you put the hook at this place, you cannot modify the tree in the pre-commit hook. All you can do is ensure that the tree is 'correct'.

An alternative "pre-pre-commit" hook would be invoked (perhaps before any data gathering?). But that can also be easily done in a plugin by installing its own 'cmd_commit'. So I'm not sure we need a pre-pre-commit hook.

[Nam Nguyen (bitsink+launchpad)]

I also concur with you that pre-commit should preferably only reports a list of modified or added files or directories to the plugin. If needed, the plugin could request a whole tree in a temporary area.

There are a few issues though.

o If a branch is large enough, each time a whole tree is requested, there will be space wastage.
o If a list of plugins is specified and each of them requests a tree for itself, do we share a same tree, or create separate trees?

It might be a solution if we create a new branch in a temp directory, apply the merge, then give it back to the plugin. When the plugin finishes using the tree, it must release it (a refcount will tell if the branch has been released). At this time, the tree is reverted, the commiting merge is re-applied, and the tree is given to the next plugin in line.

This solution can also save us some space and time because we only need one temporary space, and a pull will keep it up-to-date with the current tree.

As to the question whether a plugin can modify the tree in pre-commit hook, I think it is free to do whatever it requires but the tree will be discarded (reverted) when it is released back from the plugin. Now, this is another problem because if the plugin intentionally makes conflicting changes, and commits to that, we won't be able to do a pull on that tree to keep it updated anymore (or do we?). What if the plugin deletes the whole temporary tree? In these cases (a pull fails, or the pre-commit tree is gone), we have to create it again.

[Nam Nguyen (bitsink+launchpad)]

commited from revision 2659