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

Matt Mackall mpm at selenic.com
Fri Jan 16 00:42:32 CST 2009

On Thu, 2009-01-15 at 11:22 -0500, Jesse Glick wrote:
> 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).

I'm convinced we need to do something here.

I'd probably prefer a new hook with a less unfortunate name. I'd rather
not introduce the new python-only hook distinction either.

I might also be convinced to consider a way to make shell hg commands
work with the not-quite-committed changegroup, perhaps via a global flag
like --pending. Or maybe even an environment variable.

The environment variable would be something like

We'd set this in the hook environment and when this was present, hg
inside the hook would use it rather than the default changelog.i path
(provided it was in a sensible place).

This would still need a new hook name, and we could provide a way for
in-process hooks to see the updated repo similar to what you've done.

http://selenic.com : development and support for Mercurial and Linux

More information about the Mercurial-devel mailing list