hgeol and TortoiseHg clone?
Kurt Granroth
kurt.mercurial at granroth.com
Fri Jul 23 17:53:33 UTC 2010
On 07/23/2010 10:36 AM, Steve Borho wrote:
> On Fri, Jul 23, 2010 at 12:27 PM, Kurt Granroth
> <kurt.mercurial at granroth.com> wrote:
>> On 07/23/2010 09:53 AM, Steve Borho wrote:
>>>> It's TortoiseHg!
>>>>
>>>> So I was testing to see if named branches made any difference and if -u vs
>>>> -r mattered when I finally saw why some of my clones worked and some didn't.
>>>>
>>>> 1. All clones done via 'hg clone' properly deal with eol
>>>> 2. None of the clones done using the TortoiseHg Clone gui handle eol
>>>> correctly
>>>>
>>>> This is true on Linux, too, using 'hgtk clone'.
>>>>
>>>> Notably, it's just the Clone dialog that has issues. If I use the
>>>> Repository Explorer to 'clone to NULL; clone to tip', then it works just
>>>> fine.
>>>>
>>>> The outstanding question now is: what could TortoiseHg Clone be doing that
>>>> makes it completely skip the hgeol extension?
>>>
>>> That's a real good question, because hgtk clone
>>>
>>> #1 - loads all extensions
>>> #2 - sends a clone command line to mercurial's dispatcher
>>
>> I put some 'print' statements into eol.py and discovered that both 'hg'
>> and 'hgtk' call uisetup(), extsetup(), and reposetup(). Notably, I see
>> that uisetup() appears to register the preupdate hook? I'm not 100%
>> sure that that is what it is doing since I'm not very familiar with
>> extensions.
>>
>> Anyway, if I run 'hg clone -v', I see roughly this:
>>
>>
>> uisetup
>> extsetup
>> reposetup for
>> reposetup for
>> requesting all changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 2 changesets with 3 changes to 2 files
>> updating to branch default
>> resolving manifests
>> calling hook preupdate.eol: <function preupdate at 0xb72d080c>
>> preupdate for /tmp/hg/kurt-test: 9c45f675efbc ->
>> getting .hgeol
>> getting readme.txt
>>
>> If I run 'hgtk clone -v', I see roughly this:
>>
>> uisetup
>> extsetup
>> reposetup for
>> reposetup for
>> requesting all changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 2 changesets with 3 changes to 2 files
>> updating to branch default
>> resolving manifests
>> getting .hgeol
>> getting readme.txt
>>
>> It's nearly identical. The one crucial difference is that the
>> preupdate.eol hook isn't being called when in hgtk like it is in raw hg.
>>
>
> Just a hunch, but can you disable all extensions other than eol?
No luck. Here's some more random info: the mercurial 'hook' is being called in both cases but whereas a raw hg has hooks set in ui.configitems(), hgtk does not. I am wondering if the eol extension is being initialized in the context of one 'ui' object while the core mercurial is using another.
Using 'hg clone -v' with judicious print statements:
eol.uisetup: ui = <mercurial.ui.ui object at 0xb72c128c>
hook.hook: ui = <mercurial.ui.ui object at 0xb72c128c>
Doing the same with 'hgtk clone -v':
eol.uisetup: ui = <mercurial.ui.ui object at 0x82dc60c>
hook.hook: ui = <tortoisehg.hgtk.hgthread.GtkUi object at 0x860ef6c>
It's a completely different ui object (different type, even). Now I do see even in the raw hg that the ui object changes every so often in the run of the clone so it's clearly being copied around. Perhaps the initial ui isn't being copied into the GtkUi?
More information about the Mercurial
mailing list