We've seen some really strange behaviour with settings for disabling the eol extension in TortoiseHg today, and I'd like to see if anyone has seen anything similar (we can't find a bug for it).
The oddity is: - our user config has eol turned off, with eol = ! - in a DOS command prompt, typing "hg help extensions" showed that eol was disabled - In TortoiseHg 2.4 Log window, typing "hg help extensions" showed that eol was ENabled - Quiting TortoiseHg, removing the "eol = !", and restarting TortoiseHg showed that eol was DISabled We saw this same behaviour on another PC with TortoiseHg 2.4.1... So I was about to report a bug saying that TortoiseHg 2.4.1 appeared to interpret "eol = !" incorrectly. However, we did a bit more testing, and found that on a TortoiseHg 2.3.2 machine, with two open TortoiseHg processes, one showed eol on, and the other off - but the settings had not been changed for the lifetime of these processes. We then quit TortoiseHg and re-loaded it, and could not get it to show eol as on. Finally, having upgraded the 2.4 machine to 2.4.1, I put back the "eol = !", fully expecting to see eol as on again - and it wasn't. So, with several witnesses (honest!), we've been through several cycles of seeing inconsistent and non-reproducible behaviour of the eol extension. We have checked to ensure that the repo's hgrc doesn't enable eol. This has caused several users to find a number of files to be reported incorrectly as modified, and I am wondering whether it is also the cause of the really slow status which I described in the thread 'What events trigger a "Refresh status..."' http://sourceforge.net/mailarchive/forum.php?thread_name=20120616001222.3b233302ff425f5c7e89a4d5%40tcha.org&forum_name=tortoisehg-discuss In case it's relevant, I've given more details below of our how our settings are set up. We're stumped! Does this ring a bell, or can anyone offer any suggestions from tracking this down please? Thanks, Clare Background: In order to keep everyone's settings consistent, our hg settings look like this, i.e. the user's mercurial.ini pulls in a standard file - and that standard file says "eol = !" ------------------------------------------------- C:\Users\%USERNAME%\mercurial.ini contains: %include D:\x_mirror\buildman\tools\Mercurial\custom_scripts\Mercurial.ini [ui] username = macrae ------------------------------------------------- D:\x_mirror\buildman\tools\Mercurial\custom_scripts\Mercurial.ini contains: [tortoisehg] issue.regex = (?i)(bz|bug|bugzilla|gnats|rt|sw|scrumworks)[ /]*(\d+|[A-Za-z][A-Za-z][A-Za-z]\d*-\d+) issue.link = http://intranet.ccdc.cam.ac.uk/~buildman/ticket_redirect.php?type={1}&id={2} [ui] merge = araxis commitsubrepos = True [extensions] eol = ! checkfiles = D:/x_mirror/buildman/tools/Mercurial/custom_scripts/checkfiles.py [hooks] precommit.checkfiles = python:D:/x_mirror/buildman/tools/Mercurial/custom_scripts/checkfiles.py:precommit_hook LEGAL NOTICE Unless expressly stated otherwise, information contained in this message is confidential. If this message is not intended for you, please inform [email protected] and delete the message. The Cambridge Crystallographic Data Centre is a company Limited by Guarantee and a Registered Charity. Registered in England No. 2155347 Registered Charity No. 800579 Registered office 12 Union Road, Cambridge CB2 1EZ. ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
