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? 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
