On 09/15/2010 10:28 AM, Steve Borho wrote: > On Wed, Sep 15, 2010 at 12:04 PM, Steve Borho <[email protected]> wrote: >> On Wed, Sep 15, 2010 at 11:58 AM, Kurt Granroth >> <[email protected]> wrote: >>>> 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 > > This patch works for me. I'm waiting to hear from Martin whether this > is a good idea or not. FWIW, this is what the progress extension also > does: > > diff -r a424fa60e742 hgext/eol.py > --- a/hgext/eol.py > +++ b/hgext/eol.py > @@ -145,6 +145,7 @@ > > > def reposetup(ui, repo): > + uisetup(repo.ui) > #print "reposetup for", repo.root > > if not repo.local(): >
Steve, you are rock star! This works perfectly for me on both Linux and Windows. ------------------------------------------------------------------------------ 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
