push deadlocks (was: pull hook?)

[Lasse Kliemann]

Lasse Kliemann <lasse at lassekliemann.de> writes:

> I know that going for hgsql is probably the best solution. But why
> doesn't it work the basic way? This really intrigues me. Should it work
> in principle, as far as Mercurial is concerned?

Somewhere I read that a repos is also locked if it is the source of a
push. If this is the case, then I believe any setup like mine will lead
to timeouts.

However, I have a working solution now. The basic idea is: use short
timeouts, wait, and retry often. All my repos have ui.timeout=3 and the
hg-hook-push script now looks like this:

case "$2" in
    '') : ;;
    "$HG_URL") exit 0 ;;
    *) : ;;
esac
(bash -c 'code=255; count=0; while test $code -gt 1 -a $count -lt 100; do hg push -f '"${1?}"'; code=$?; count=`expr $count + 1`; sleep `expr $RANDOM % $count`; done'  > /dev/null 2> /dev/null < /dev/null &)
exit 0

Of course, the details of the retry-loop can be implemented in many
different ways.

The scripts that my users have for pulling and pushing are also
configured to retry a number of times (5 at the moment).

I've tested with 4 clients pulling and pushing simultaneously in short
succession, it is ok. I know that 4 are not many, but before not even 2
could be handled correctly, so this is an achievement.

All in all not a nice solution, but it works for now. I'll let the
matter rest.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150503/97bfea49/attachment.asc>