[PATCH] 1321 (partial): run Python pretxnchangegroup hooks before disk flush

Jesse Glick jesse.glick at sun.com
Thu Jan 15 10:22:48 CST 2009


Doug Philips wrote:
>> 1321 (partial): run Python pretxnchangegroup hooks before disk flush.
> 
> Other issues aside, this would imply that an in memory python hook could not "call out" (subprocess, etc) to an external program?

It could. But if for some reason it happened to (perhaps indirectly) call out to the 'hg' executable, that instance of Hg would not see the pending changesets.

Having an in-process hook which winds up calling the external hg executable seems perverse to me - you will lose the power & speed of the in-process hook, so you might as 
well have used an external hook to begin with - but it is possible someone is doing it. If so, it would be straightforward to have an option to run the in-process hooks 
after the flush as in current releases.

Another option would be to run pretxnchangegroup hooks exactly as they are now, but introduce a new hook such as pretxnflushchangegroup, documented to run before the 
flush and aborting in case you tried to pass an external hook (unless and until this is implemented somehow).


By the way, the cautionary tale in

http://hgbook.red-bean.com/hgbookch10.html#x14-20400010.3

seems a bit of a strawman to me:

"In principle, a good use for the pretxnchangegroup hook would be to automatically build and test incoming changes before they are accepted into a central repository. 
This could let you guarantee that nobody can push changes to this repository that “break the build”."

Continuous integration is a well-accepted mechanism for ensuring that a source base meets various quality criteria. If you want to avoid pushing or pulling a revision 
which does not build or which fails critical tests, there are plenty of ways of doing this that do not rely on SCM hooks: tagged "known good" revisions, "stable" vs. 
"experimental" repositories or local branches, etc. These systems generally mean that a record of mistakes is in history but mistakes are followed by corrections, which 
for many projects is fine.

Section 10.3.1 implies that although pretxnchangegroup can be made to work with a unidirectional "gate" repo, you don't really need such hooks to begin with. But if you 
exclude CI-type hooks (those ensuring that committers have not made honest correctable mistakes), there are plenty of other controlling hooks that can be useful, where 
you really want to prevent rejected changesets from propagating into permanent history. These include:

- win32text (rejecting CRLF)
- acl (rejecting unauthorized changes)
- checking for missing license headers or third-party content
- checking for excessively large (generally binary) files
- checking for accidentally included passwords
- enforcing site policy for named branches or multiple heads
- enforcing site policy for user name or comment format
- enforcing site policy for code formatting (correcting it later will damage line history)

Most hooks like this can run fast enough to not become a bottleneck, and permitting unverified changesets to "leak" to other clients trying to pull concurrently could be 
disastrous in some cases. That is why I am trying to get #1321 fixed.



More information about the Mercurial-devel mailing list