On Wed, Sep 15, 2010 at 11:58 AM, Kurt Granroth <[email protected]> wrote: > On 09/11/2010 08:47 PM, Kurt Granroth wrote: >> On 9/8/10 7:32 PM, Steve Borho wrote: >>> 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 > > FWIW, I tried this again on Linux using hgtk just to make sure: > > 1. Using hgtk from tortoisehg-stable (tag 1.1.3, rev 8199). Hg 1.6.2 > 2. $HOME/.hgrc has: > > [extensions] > eol= > > [eol] > native = CRLF > 3. hgtk clone http://hg.granroth.org/eol > 4. The clone produces one 'readme.txt' file with LF line endings > (verified using gvim) > 5. Update to revision NULL (-1). Update back to revision 0. > 6. The 'readme.txt' file now has CRLF line endings (verified using gvim). > > So it's the exact same on Linux as it is on Windows. Every time I clone > http://hg.granroth.org/eol using TortoiseHg, the 'eol' extension will > *not* activate and the file remains in LF line endings until forced > otherwise. > > Also, for the record, I did 'hg clone http://hg.granroth.org/eol' using > the same .hgrc and it properly encoded the file with CRLF. > > I am beyond baffled if nobody else is seeing this since, well, 100% > reproducible on multiple systems for me! Is it maybe my repos? Does > anybody see anything odd about the repo I'm using for this test?
I can repro this as well. I'll try allocate some time to track the root cause -- Steve Borho ------------------------------------------------------------------------------ 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
