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? -- Steve Borho ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
