Mercurial push locks

[Simon King]

On Mon, Sep 29, 2014 at 4:41 PM,  <durwin at mgtsciences.com> wrote:
> Simon King <simon at simonking.org.uk> wrote on 09/27/2014 03:14:15 PM:
>
>> From: Simon King <simon at simonking.org.uk>
>> To: durwin at mgtsciences.com
>> Cc: Matt Mackall <mpm at selenic.com>, Mercurial mailing list
>> <mercurial at selenic.com>
>> Date: 09/27/2014 03:14 PM
>> Subject: Re: Mercurial push locks
>>
>> On 27 Sep 2014, at 00:16, durwin at mgtsciences.com wrote:
>>
>> > Matt Mackall <mpm at selenic.com> wrote on 09/26/2014 03:30:00 PM:
>> >
>> > > From: Matt Mackall <mpm at selenic.com>
>> > > To: durwin at mgtsciences.com,
>> > > Cc: Mercurial mailing list <mercurial at selenic.com>, Simon King
>> > > <simon at simonking.org.uk>
>> > > Date: 09/26/2014 03:30 PM
>> > > Subject: Re: Mercurial push locks
>> > >
>> > > On Fri, 2014-09-26 at 11:19 -0600, durwin at mgtsciences.com wrote:
>> > > > > > > With the introduction of phases (Mercurial 2.1, Feb 2012),
>> > > > > > > pushes
>> > > > may
>> > > > > > > now acquire a lock on the sending side (so that it can update
>> > > > > > > the
>> > > > phase
>> > > > > > > of local commits). Thus, you may get a deadlock if you
>> push inside a
>> > > > > > > hook where a lock is already held.
>> > > > > >
>> > > > > > This appears to what is occurring.  Is there a way around this?
>> > > > > > I
>> > > > need to
>> > > > > > perform a push
>> > > > > > to the other repository after each push to either.  ShouldI
>> > > > > > change
>> > > > this
>> > > > > > to a script and
>> > > > > > run it in an 'at' job delayed a minute?
>> > > > >
>> > > > > What version of Mercurial are you running on the server?
>> > > >
>> > > > Mercurial version 2.6.3
>> > >
>> > > Hmmm, shouldn't be a problem here: the changegroup hook is run
>> > > immediately after lock release.
>> > >
>> > > Perhaps you can create a minimal model of your flow:
>> > >
>> > > $ hg init local
>> > > $ hg init server1
>> > > # add push hook
>> > > $ hg init server2
>> > >
>> > > ..and see if you can get it to lock.
>> >
>> > I do have a 'test' repository where all I have are two files.  The
>> hook always works for me.  In fact the project repository all ways
>> works for me.  There was a time where I would see the lock, but that
>> is no longer occurring.  I tried logging into server as one of the
>> users having the problem and cloned their repository, but it would
>> not lock up, it pushed just fine.
>> >
>>
>> I’m not sure I understand your setup here. Based on your earlier
>> emails you say you have:
>>
>> Local machine
>>   -> push to ssh://server//home/svnuser/project-hg/WebApplication
>>     -> changegroup hook pushing to
>> /home/svnuser/project-hg/WebApplication/
>>
>> This doesn’t appear to make any sense (changegroup hook pushing to
>> the current repository), so perhaps you’ve changed the paths and
>> they’re not really like this.
>>
>> For the first push, I assume that each user has their own account on
>> the server, but file permissions are set up such that they all have
>> write privileges on the first server-side repo. This is a potential
>> source of problems if the users don’t have appropriate umask and
>> group settings, as one user could create files that can’t be updated
>> by other users.
>>
>> The hook then uses sudo to run the second push as the user
>> “svnuser”, and it calls a program called “hg-svnuser”. This raises a
>> couple more questions:
>
>
> I have 2 servers, each with a clone of the project.  Webuser works off
> ServerA,
> while the rest work off ServerB.  When a push is done to ServerB, it must
> then
> push to ServerA.  I copied hg executable to hg-svnuser then set the SUID
> and the user to 'svnuser' with the intent on getting consistent properties.
> Every user is in the 'svnuser' sudo group with NOPASSWD defined for
> hg-svnuser executable.

If that works for you, that's fine. An alternative approach is to put
ssh keys for each of your users in the authorized_keys file for
svnuser, then have everyone push using that account. Because all
operations on the server are then run as svnuser, all your permissions
should be consistent, and there would be no need for sudo, or the
separate SUID script). This approach is described at
http://mercurial.selenic.com/wiki/SharedSSH (hg-ssh) and
https://sites.google.com/site/ucdcsssg/announcements/howtocollaborateusingmercurialwithhg-ssh.

(Does making "hg-svnuser" SUID actually work? I thought that wasn't
generally possible for scripts)

>
>>
>> 1. Do all users have the same sudo privileges? Perhaps the blocking
>> happens because sudo is trying to prompt for a password in some cases?
>>
>> 2. Is “hg-svnuser” a different installation of mercurial than the
>> one invoked as part of the “initial” push? If so, have you checked
>> the version numbers of both installations?
>>
>> I don’t know what you mean when you say you logged into the server
>> as a different user and cloned their repository - perhaps you could
>> explain those steps in detail.
>
> I had logged into one users login on ServerB to see if I can duplicate
> problem.
>
> $ ssh user1 at serverb
> $ hg clone ssh://serverb//home/svnuser/project/ project/
>

I see. The permissions on the "local" clone (that one that initiates
the original push) are unlikely to be relevant - I think you could
done a similar test by pushing from your own clone, but specifying the
other user's account in the ssh url. ie.

  hg push ssh://user1@serverb//home/svnuser/project

> Then make an edit, commit, then push.
>
> None of the users are actually working *on* the server.  They are using
> Windows,
> most using Netbeans, one using Cygwin.
>
> I even had one create a new clone, but still had lockups.
>
> I did remove the hook for testing and there was no lockups.
> I am trying to recode hook to perform a push to other server *after* user
> has
> competed (using at).
>

I still feel that your problem is permission-related, in which case
changing the time at which the secondary push happens won't fix the
problem. You may find that your "at" job hangs instead, and if it
locks the repository, you will only find out when the *next* person
tries to push and can't...

Did you look at the file permissions and ownership in the 2
repositories, particularly in the .hg/cache directory?

Simon