[RFC] Pre-commit hooks and other requests

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Before I go overboard restructuring commit, I'd like to have a feel for
>  any future features that are *likely* to be requested. For example,
> right now commit supports hooks for code to execute after a commit is
> successful. Is there a need for pre-commit hooks or some "mid-commit" hooks?

I think a 'mid-commit' hook is genuinely useful. So after the revision has been
generated (so all the texts being committed are fixed), but before the Branch
has been updated.

Some things you could do "mid" you could also do with a "pre" or a just a
commit wrapper. But I think that would lead to pre-commit hooks re-implementing
(possibly poorly) all of the work that commit has to do to figure out what has
been changed that is included in a partial commit. Since commit has already
done whatever delta is needed it could just pass it to the mid-commit hook.

Even if we make commit fast by not doing file-level deltas, I think there will
always be some amount of tree-wide delta that has to be computed. (What new
texts are being saved, etc).

> 
> I'm not looking to over-design things upfront here, just raise my
> awareness of any likely logical constraints down the track. In
> particular, the current code does several "startup" checks (e.g.
> checking for unknowns in strict mode) before beginning the commit "main
> loop". I'm planning to combine those where I can, i.e. check for
> unknowns in the main loop and abort if any are found. As things stand
> right now, that's something I can do because it's just an implementation
> detail. If a hook is likely to be required *after* the checks but before
> the main loop, then the situation is potentially different.
> 
> I appreciate that this is not black-and-white: commit can still be doing
> tests of some sort or another right up until the final transaction than
> delivers a new revision. I did want to ask the question openly though so
> that the refactored commit code continues in the right direction from a
> logical design perspective (as well as a physical design one). So ...
> 
>   What features is commit missing that I ought to have in the
>   back of my mind?
> 
> Ian C.


One other possible constraint is from the 'bzr-svn' plugin. Specifically, when
trying to create a bzr checkout of an svn repository, it would be nice to be
able to have the SVN repo define the revision id, rather than the local Bazaar
branch. I believe Jelmer has probably worked around this, by adding SVN
properties which allow him to mark an SVN revision with a Bazaar revision id.
Even so, there may be other formats in the future that don't have that flexibility.

His original plan was to do the commit on the master, and then pull it to the
local branch. But that has some bad performance implications when Master is a
remote branch over a 100ms latency link.

I don't know if it would be enough to ask the Master branch for
file-ids/revision-ids. And then do the work locally, and mirror it up.

Then again, if bzr-svn wants "true push" it needs to have a way to map Bazaar
revision ids into svn anyway.

Anyway, I just wanted to mention that we may want the ability to have a bound
branch be able to alter some amount of flow, without having it impact
performance substantially.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGgR07JdeBCYSNAAMRAu32AKCpTYpmsqoThVONjsCIG8ZQlaMqvACfVC87
L7qOMYK1ku0v2/OgMHTMTWY=
=na22
-----END PGP SIGNATURE-----