On 05.07.2010 08:10, TK Soh wrote: > 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. > >
I think I've seen a possible angle where this could be addressed in the code (new case in Direntry::status, and layers higher up). I'm just a bit wary of wasting my unpaid time on this one. I can't remember having seen lot's of complaints about this boundary case (other than you). I mean, open source is very cheap for the users, but in the end, someone has to do the work... (and it doesn't look like anyone would pay anything anytime soon for things like this one here). ------------------------------------------------------------------------------ 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
