David Marker wrote:
> Dean Roehrich wrote:
>
>> On Thu, Aug 07, 2008 at 06:54:11PM -0700, David.Marker at sun.com wrote:
>>
>>
>>> Author: David Marker <David.Marker at sun.com>
>>> Repository: /hg/scm-migration/onnv-gk-tools
>>> Latest revision: 13c87b174da31bebe6de23f5ad9a4ecbdfbcb4ef
>>> Total changesets: 1
>>> Log message:
>>> HOME environment var almost always needs to be set for hg and trust.
>>> Fix other boneheaded mistakes I made (sadly only discovered while running
>>> on gate).
>>> Finally update config so it exists outside just gate repos.
>>>
>>> Files:
>>> update: clone-closed-hgrc
>>> update: clone-hgrc
>>> update: etc/config.py
>>> update: gate-closed-hgrc
>>> update: gate-hgrc
>>> update: hook/notify.py
>>> update: lib/mail.py
>>> update: lib/utility.py
>>> update: on-hg.py
>>> update: periodic/incremental.py
>>> update: periodic/nightly-build.py
>>>
>>>
>> David,
>>
>> While the changegroup.x hooks are running in gate-hgrc I don't see how you're
>> preventing a new changegroup from arriving. I guess I expected changegroup.0
>> would use hg push --rev for this situation.
>>
>> Maybe the hg update should use --clean and --rev in gate-hgrc, or maybe it
>> shouldn't be there at all. That update could run while a new changegroup is
>> in the pretxnchangegroup hooks. And why do you need update on both the push
>> and the pull gates (I guess you call them 'gate' and 'clone')? I think hg
>> update in 'gate' is a good way to create a bit of confusion.
>>
>> Dean
>>
>>
>
> I think you will find that the push lock is held until even changegroup
> hooks are run.
>
> def push_addchangegroup(self, remote, force, revs):
> lock = remote.lock()
> try:
> ret = self.prepush(remote, force, revs)
> if ret[0] is not None:
> cg, remote_heads = ret
> return remote.addchangegroup(cg, 'push', self.url())
> return ret[1]
> finally:
> del lock
>
>
> Notice it is inside addchangegroup() that both pretxnchangegroup and
> changegroup hooks are run.
>
> Am I missing something?
>
> Anyway people still use cscopt from NFS for "gate" repo. So I do need to
> have it updated.
>
> If I am wrong about lock being held for the duration of the "push" (even
> the changegroup hooks) then I agree I have a problem and should use "--rev".
>
> -dvd
>
>
My reasoning may have been flawed, but Rich also didn't think it was
possible.
Finally I created a parent repo with these hooks to see what happened:
changegroup.0 = touch /tmp/changy.${HG_NODE}
changegroup.1 = sleep 60
The reason I touch a file is cause you don't get any output from ssh
till its all over.
So one child repo is going to have to "push -f" to overcome the creation
of a new head.
Anyway the result I saw was that the second push had to wait.
I repeatedly did `hg log -l1` while both waited for sleep.
So the first push gets in right away.
Then waits 60 seconds.
During that time you can see it with `hg log -l1`
The second one does *not* show up.
Which means a push to the clone won't pick it up.
Nor should `hg update`.
So I'm pretty confident the hooks don't need --rev.
At least not with our current version of Mercurial :)
-dvd
