On Sun, Jul 4, 2010 at 12:12 PM, Adrian Buehlmann <[email protected]> wrote: > On 04.07.2010 08:51, TK Soh wrote: >> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <[email protected]> wrote: >>> On 02.07.2010 09:17, TK Soh wrote: >>>> I am rather confused on something about the overlay icons (using thg >>>> 1.1) on Windows XP (32bit, SP3): the overlay icon of modified file >>>> changes to 'modified' almost immediately after I edit and save a file. >>>> But the icon remains as 'modified' after I undo the edit and save the >>>> file. I am aware I can run "Update Icons" to refresh. Maybe I am >>>> missing something >>>> >>> >>> Hello Tk, it's been a while since you posted here :-) >> >> Some circumstances have prompted me to pay more attention to >> TortoiseHg, especially for Windows. BTW, I've looked forward to your >> response on this thread also ;-) >> >>> That's an effect of the shell extension's design, which is a trade-off >>> between speed, intruding windows processes with python.dll/mercurial or >>> not and overlay icon state accuracy. >>> >>> A trade-off that has been discussed quite a number of times on the >>> TortoiseHg mailing lists already (IMHO, ad nauseum). >> >> I'm sure you and other has spend a lot to discuss this. Given the >> potential circumstances where I might be using TortoiseHg (on Windows) >> a lot more, I'd like to understand the topic a bit more. So, I'd >> appreciate if you can bear with me. >> >>> In the use case you cite, the file's timestamp is newer than the file's >>> timestamp in .hg/dirstate, but the file size hasn't changed (because of >>> you undoing the file edit). >> >> I am slightly confused. Do you mean the status of a file is somehow >> depending it's mod time and size? I wonder what are the underlying >> logic/algorithm here. >> >>> This state needs a file compare to resolve correctly, which the shell >>> extension won't do by design (because of the design trade-off choosen). >> >> Is there any documentation somewhere (in the source perhaps) on the >> design? Or you can share a few line if you don't terribly mind doing >> so. >> >>> Try running a 'hg status' in that repo in that case -- mercurial will >>> update .hg/dirstate and the shell extension will display the correct >>> icon again (unmodified), even without hitting the F5 key (refresh) in >>> Windows explorer. >>> >>> It might be possible to trigger TortoiseHgOverlayServer.exe from the >>> shell extension in this case too, which basically does the same as 'hg >>> status' to update .hg/dirstate. In some cases, this already works >>> automagically, but apparently not in this one. >>> >>> Perhaps someone might come-up with a fix fir this specific case which >>> triggers TortoiseHgOverlayServer.exe in this case as well. Just make >>> sure you don't introduce any endless loops here -- I've been wary of >>> these when I made the current overlay handler. >>> >>> "Update icons" will update .hg/dirstate manually though, as you already >>> found out. Which is good enough for me for this case. >> >> Several people I worked with had used TortoiseSVN find this confusing, >> and the need to use "Update icons" is rather cumbersome. I hope we >> could resolve this. >> >>>From the users' stand point, the overlay icons should provides >> up-to-date info as soon as possible. Else we might as well use the >> status dialog to get the repo status, since it take a same amount of >> work (menu clicks) to achieve that. > > That's exactly the kind of discussion I'm not at all interested to rehash.
Fair enough. Hopeful someone else can take on the issue soon. ------------------------------------------------------------------------------ This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first _______________________________________________ Tortoisehg-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
