On Thu, 25 Nov 2010 11:56:22 +0100, timeless <timel...@gmail.com> wrote:
On Thu, Nov 25, 2010 at 12:18 PM, Frank Batschulat
<frank.batschu...@oracle.com> wrote:
[hooks]
changegroup.update =
/builds/batschul/zoss-gate/zoss-merge/.hg/incoming-hook
the hook does email and this:
# Update the repository working image to the tip
hg update
So,.... you have a hook for 'update' which would be called roughly when
you did:
hg update
and that hook runs a script which is called 'incoming-hook', which
seems misnamed.
that hook then calls hg update. which is where you were when you
triggered the hook.
It seems more likely that your hook was supposed to be
changegroup.incoming = ...
Basically the hook ran while holding the repository lock and tried to
trigger itself which failed (which is good since you were trying to
trigger infinite recursion).
thanks! yeah seems like I created a recursion, because our
"hg recommit" addon does also an "hg update" so my hook caused
an 'hg update' within a 'hg update' from the 'hg recommit'.
wrt. to changegroup.incoming vrs. changegroup.update
changegroup
Run after a changegroup has been added via push,
pull or unbundle. ID of the first new changeset is
in $HG_NODE. URL from which changes came is in
$HG_URL.
incoming
Run after a changeset has been pulled, pushed, or
unbundled into the local repository. The ID of the
newly arrived changeset is in $HG_NODE. URL that was
source of changes came is in $HG_URL.
I'm not sure about the difference in action based on the hgrc(5)
explanation though. ie. what will be different in behavior.
thanks,
frankB
_______________________________________________
tools-discuss mailing list
tools-discuss@opensolaris.org
