On 06.07.2010 02:24, Adrian Buehlmann wrote: > On 06.07.2010 01:29, Adrian Buehlmann wrote: >> 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). > > The trick I'm thinking about is for file X with state 'n' (normal) in > .hg/dirstate (see 'hg debugstate'), if the mtime of X is not equal to > the mtime in .hg/dirstate of X but the sizes are equal, we insert a call > to Thgstatus::update(), which will trigger TortoiseHgOverlayServer.exe > to update .hg/dirstate, which will then pick up the new mtime for that file.
... but then we have to protect against the endless loop for the case where X was really modified without changing the size (in which case the mtime in .hg/dirstate for X will not be updated by 'hg status'). See what I mean about the work needed to fix this case? My interest in this case is dropping to near zero again... ------------------------------------------------------------------------------ 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
