On 9/8/10 7:32 PM, Steve Borho wrote: > On Mon, Aug 9, 2010 at 9:48 AM, Steve Borho<[email protected]> wrote: >> On Sun, Aug 8, 2010 at 9:25 AM, Yuya Nishihara<[email protected]> wrote: >>> Kurt Granroth wrote: >>>> On 08/01/2010 09:33 AM, Yuya Nishihara wrote: >>>>> Kurt Granroth wrote: >>>>>> The problem is that the hooks are attached to the "wrong" UI object. >>>>>> >>>>>> Okay, so hgtk.run() calls 'extension.loadall(ui)'. This is the function >>>>>> that calls the extensions' uisetup()... and this is where the necessary >>>>>> hook is setup so that hgeol is called during the update. So far, so >>>>>> good. >>>>> >>>>> I don't read full story yet, but Mercurial also calls extensions.loadall() >>>>> with lui, which is copy of ui. (see dispatch.py:_dispatch().) >>>>> It means preupdate.eol hook doesn't take effect in most cases. >>>>> >>>>> in-hg-repo% hg update # doesn't call eol.preupdate() >>>>> out-hg-repo% hg clone foo bar # calls eol.preupdate() >>>>> in-hg-repo% hg clone . ../bar # doesn't call eol.preupdate() >>>>> >>>>> It's only effective for clone only when you're outside ouf repository. >>>> >>>> I got almost exactly the *opposite* results of your test, in my earlier >>>> testing. That is, eol.preupdate() ran with 'hg update' but did not run >>>> with 'hg clone'. >>>> >>>> Actually, to be a bit more precise: hg clone *did* appear to work when >>>> the repositories were local (file://) but did not when the source repo >>>> was remote (ssh:// or http://). >>>> >>>> I don't think calling extensions.loadall() will do anything useful. The >>>> core extensions code uses a few global variables to ensure that hooks >>>> are only loaded once. >>> >>> I cannot figure out what makes difference. >>> Here's my understanding: >>> >>> uisetup() is called only by extensions.loadall(), and where calling >>> extensions.loadall() are: >>> % grep loadall *.py >>> dispatch.py: extensions.loadall(lui) >>> dispatch.py: # (uisetup and extsetup are handled in extensions.loadall) >>> extensions.py:def loadall(ui): >>> localrepo.py: extensions.loadall(self.ui) >>> >>> * If current directory is inside repo, _dispatch() copies ui to lui to load >>> local .hg/hgrc; then calls extensions.loadall(lui). >>> * If source repo of 'hg clone' is local, localrepository() will load its >>> .hg/hgrc followed by extensions.loadall(self.ui). Here self.ui is copy >>> of self.baseui. >> >> I could see this being a problem if the eol extension is only enabled >> in the source repository .hg/hgrc file. TortoiseHg does not look >> there for extensions to enable. > > I spent some time today trying to reproduce this problem using the > steps in the initial email and I was unable to make eol *not* update > the newly cloned repository with the proper line endings. > > My steps (using hgtk 1.1.3, hg 1.6.3): > > 1) enable eol in user Mercurial.ini > 2) hg init eol ; cd eol ; vim test.txt > 3) give test.txt unix eoln, save, hg add, hg ci > 4) create the .hgeol file described in the original email, hg add, hg ci > 5) hg up 00000, hg up. test.txt is now in dos eoln > > Next I cloned the eol repo to eol2, eol3, eol4, etc using as many > variations of starting the hgtk clone tool as I could think of. > test.txt files in each clone were in dos eoln. > > What do I need to do to reproduce this? >
I believe the key is to clone over a network. Here's the simplest test I have that reproduces this issue 100% for me. 1) I do a clean install of TortoiseHg 1.1.3 on a Windows XP SP3 VM. I pare down an ultra-minimal mercurial.ini: [extensions] eol = Nothing more! 2) I then use the TortoiseHg Clone dialog with this Source and Target: Source Path: http://hg.granroth.org/eol Destination Path: C:\Documents and Settings\Kurt Granroth\My Documents No other options are set. 3) The clone produces one 'readme.txt' file that was originally encoded with LF line endings. Open that file using something like Notepad. Notice that it *still* has LF line endings. 4) Update to revision NULL (-1). Update to revision 0. 5. Open 'readme.txt' using Notepad. Note that it has CRLF line endings. I did this test using a local clone and the eol extension kicked in during the clone. That strongly implies to me that this is related to clone over a network. Anyway, this is 100% reproducible for me on every system I test on (Windows and Linux). I tried to strip this down to the bare essentials using fresh installs in a VM just to make sure. Yep, it still happens. Kurt ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
