hg notify inter-repo mechanics

[Simon King]

On Mon, Jan 5, 2015 at 2:06 PM, John Turner <jjturner at energi.com> wrote:
> On Sun, 04 Jan 2015 15:35:34 -0500, Simon King <simon at simonking.org.uk>
> wrote:
>
>>
>>> On 4 Jan 2015, at 01:28, John Turner <jjturner at energi.com> wrote:
>>>
>>> On Sat, 03 Jan 2015 09:20:57 -0500, Mads Kiilerich <mads at kiilerich.com>
>>> wrote:
>>>
>>>> On 01/02/2015 07:31 PM, John Turner wrote:
>>>>>
>>>>> On Thu, 01 Jan 2015 13:40:13 -0500, Mads Kiilerich
>>>>> <mads at kiilerich.com> wrote:
>>>>>
>>>>>> On 12/29/2014 06:34 PM, John Turner wrote:
>>>>>>>
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I'm seeking some clarity on the mechanics and/or best-practices for
>>>>>>> implementation of hg notify, namely, which side of the execution
>>>>>>> chain
>>>>>>> should invoke the mail notification, given a local(n) <-->
>>>>>>> centralized(1) workflow.
>>>>>>> ..
>>>
>>>
>>>>>>> .. My initial
>>>>>>> expectation was that the passive repo (i.e., the central repo) would
>>>>>>> invoke the mail notification, and thereby obviate the need to define
>>>>>>> a
>>>>>>> notify config for each local developer, but it appears that hg notify
>>>>>>> executes from the active repo only.
>>>>>>
>>>>>>
>>>>>> Correct, doing it on the central server makes more sense than doing it
>>>>>> on the "client" side.
>>>>>>
>>>>>> The server side hg is however not "passive". The example in the
>>>>>> beginning of "hg help notify" shows how to use hooks that will be
>>>>>> invoked on the server side when a client push changes.
>>>>>>
>>>>>> /Mads
>>>>>
>>>>>
>>>>> Thanks for offering your advice on this Mads.
>>>>>
>>>>> Hmm... so far no matter what I do, my client-side push does nothing to
>>>>> invoke the server-side hooks.
>>>>
>>>>
>>>> Then you have to debug your server side setup.
>>>>
>>>> I don't think you have told us anything about your server side setup so
>>>> any advice will probably be wrong.
>>>>
>>>> /Mads
>>>
>>>
>>> The the canonical central repo exists on a Windows 2008 R2 box.
>>> The directory owner of the central repo is a shared domain account:
>>> 'companydomain\devadmin'
>>> (this is the account we normally rdp with to work directly in this
>>> server)
>>>
>>> At the same time, I've added my personal domain account to the
>>> server-side Administrators group, and I've also added my account as a share
>>> on the actual server-side repo directory (allowing me to map it on my local
>>> machine, and generally to perform source control operations between my local
>>> repo and the server repo without running hgweb).
>>>
>>> The directory owner of my local repo is "Administrators" (as opposed to
>>> the shared domain account referenced above, which I suspect may be part of
>>> the issue..)
>>>
>>> Interestingly, when I enable the notify hook on my local machine, and
>>> push from the rdp-connected server (with server-side notify disabled), it
>>> DOES send the email - and returns the changegroup hook when I run 'hg
>>> showconfig hooks' from the server's CLI.
>>>
>>> However, the converse is not true - 'hg showconfig hooks' run on my local
>>> machine CLI with notify locally disabled, and server-side notify enabled
>>> yields nothing.  At the same time 'hg showconfig hooks' run on the
>>> server-side CLI via rdp returns the changegroup hook reference.
>>>
>>> So I'm 3 for 4:
>>> - local notify enabled and local push to central sends email
>>> - central notify enabled and central push to local sends email
>>> - local notify enabled and central push to local sends email
>>>
>>> ..and trying to solve for central notify enabled and local push to
>>> central.
>>>
>>> Hope that gives enough background for anyone and isn't too confusing.
>>>
>>> Cheers,
>>> John
>>>
>>
>> How are you enabling and configuring the notify extension on the server?
>> In the repository’s hgrc file, or in a different config file? Your original
>> mail mentioned “mercurial.ini”, which suggests that you’re configuring this
>> in the config file for a *user* on the server (eg.
>> C:\Users\devadmin\mercurial.ini).
>>
>> If you are pushing to a repository on a mapped network drive, then as far
>> as mercurial is concerned this is a “local” push. There is only a single
>> “hg” process running (as opposed to pushing over http or ssh, where there
>> are 2 hg processes running). The user account that owns the remote
>> repository is not particularly relevant - mercurial is simply performing
>> filesystem operations directly in the repository. Mercurial doesn’t even
>> need to be installed on the server for this to work.
>>
>> However, this also means that mercurial won’t load a user config file from
>> the remote server. The only config file it will read from the server will be
>> the one inside the repository itself, at <repo>/.hg/hgrc. This is where you
>> would need to configure the notify extension.
>>
>> In this configuration, it is still your client-side hg process which is
>> actually loading the extension and sending the email. If you need the email
>> to be sent by the server, then you need to be connecting to an hg process
>> running on the server, either via ssh or http (hgweb).
>>
>> Hope that helps,
>>
>> Simon
>
>
> Thanks Simon, this clears things up quite a bit!
>
> (and for the record, it is the C:\Users\devadmin\mercurial.ini file that I'm
> testing with)
>
> Given the realities - small dev team, an unfun/unsuccessful first pass at
> setting up hgweb on IIS, and not relishing an alternative foray of setting
> up ssh connectivity, I think I'll opt to stay with the "local" setup.
>
> So if I understand you correctly, I can enable the notify extension on each
> dev's machine with shares to central repo - wherein the <repo>\.hg\hgrc
> config file will be defined for *how/when* to send the email (rather than in
> the central %HOME%\mercurial.ini) - but the actual email gets generated on
> the client/local side based on that config.  Does that sound feasible?
>

If you're going down this path, I think you can do *all* the
configuration in the central <repo>\.hg\hgrc file (including enabling
the notify extension itself) - you wouldn't need to configure anything
at all on each dev machine.

By default on Unix, mercurial would refuse to read a config file that
is owned by another user, since config files effectively contain
executable code (http://mercurial.selenic.com/wiki/Trust). However, it
looks like that doesn't apply on Windows:

http://selenic.com/hg/file/42908c3275c6/mercurial/ui.py#l120
http://selenic.com/hg/file/42908c3275c6/mercurial/windows.py#l184

If that ever changes, you would need to configure the dev machines
such that they trust the user account owning the config file.

I think your setup does sound feasible, particularly for a small team,
but I think it's fair to say that hgweb or ssh would be the preferred
setup. If IIS was causing a problem, perhaps you could consider
running hgweb standalone?

Simon