TortoiseHg

[Please do not mail me a copy of your followup]

I've also noticed that the icon status goes stale.

I don't know if thg adopted the same algorithm for icon updates as
TortoiseSVN, but tsvn has been broken for years now.  The author of
tsvn always seems to lay the blame at externalities, but there was a
time when tsvn *always* got the status right and then at some point it
was just broken and its never worked right since.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Fri, Jul 2, 2010 at 11:50 AM, Richard
<legalize+jeeves@...> wrote:
> [Please do not mail me a copy of your followup]
>
> I've also noticed that the icon status goes stale.
>
> I don't know if thg adopted the same algorithm for icon updates as
> TortoiseSVN, but tsvn has been broken for years now.  The author of
> tsvn always seems to lay the blame at externalities, but there was a
> time when tsvn *always* got the status right and then at some point it
> was just broken and its never worked right since.

TortoiseHg's overlays are a completely separate implementation from
TSVN, we only share icons and overlay slots with them.

Our "staleness" problems all originate from the fact that the shell
extension is C++ and Mercurial is Python.  Synchronizing state between
them is not a deterministic process, thus the presence of the 'update
icons' feature.

-- 
Steve Borho

On Fri, Jul 2, 2010 at 5:04 PM, Steve Borho <steve@...> wrote:
> On Fri, Jul 2, 2010 at 11:50 AM, Richard
> <legalize+jeeves@...> wrote:
>> [Please do not mail me a copy of your followup]
>>
>> I've also noticed that the icon status goes stale.
>>
>> I don't know if thg adopted the same algorithm for icon updates as
>> TortoiseSVN, but tsvn has been broken for years now.  The author of
>> tsvn always seems to lay the blame at externalities, but there was a
>> time when tsvn *always* got the status right and then at some point it
>> was just broken and its never worked right since.
>
> TortoiseHg's overlays are a completely separate implementation from
> TSVN, we only share icons and overlay slots with them.
>
> Our "staleness" problems all originate from the fact that the shell
> extension is C++ and Mercurial is Python.  Synchronizing state between
> them is not a deterministic process, thus the presence of the 'update
> icons' feature.

IIRC, the pure-python shellext in the very old tortoisehg (before
switching to C++ version) didn't have problem on the conditions I
described. I don't understanding how the shellext work any longer. but
I wonder what lead to the stateless problem. Could it be due to the
dirstate approach (not sure it's really in use) and/or the caching
mechanism?

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 :-)

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).

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).

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).

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.

> 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.

Just a side issue: I used Microsoft's TFS in my last job, and as I recall it didn't attempt to use Explorer overlays. It had a dedicated app to show file/folder status (or showed them via Solution Explorer in Visual Studio).

 

If M$ can't solve the problem of good overlay refresh, maybe it can't be done?

On Sat, Jul 3, 2010 at 10:49 AM, John Sparrow
<johnsparrowuk@...> wrote:
>> 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.
>
> Just a side issue: I used Microsoft's TFS in my last job, and as I recall it
> didn't attempt to use Explorer overlays. It had a dedicated app to show
> file/folder status (or showed them via Solution Explorer in Visual Studio).
>
> If M$ can't solve the problem of good overlay refresh, maybe it can't be
> done?

That speaks volumes about the difficult nature of the problem.

-- 
Steve Borho

[Please do not mail me a copy of your followup]

Adrian Buehlmann <adrian@...> spake the secret code
<4C2F3A00.4070501@...> thusly:

>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).

If you could provide a link to the earlier discussion, I would like to
read up on the details.

>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).

In my case, the icons are often stale after I do a commit.  It shows
as modified even though everything is committed.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On 03.07.2010 22:08, Richard wrote:
> In my case, the icons are often stale after I do a commit.  It shows
> as modified even though everything is committed.

At the risk of getting yet another one of your lame linkspam posts:
works just fine here.

[Please do not mail me a copy of your followup]

Adrian Buehlmann <adrian@...> spake the secret code
<4C2F9E4E.6@...> thusly:

>On 03.07.2010 22:08, Richard wrote:
>> In my case, the icons are often stale after I do a commit.  It shows
>> as modified even though everything is committed.
>
>At the risk of getting yet another one of your lame linkspam posts:
>works just fine here.

I don't understand your pejorative remark.  Perhaps you are unfamiliar
with usenet signatures?

At any rate, I didn't say it happens *every* time I do a commit.  I
have yet to be able to identify a set of circumstances that reproduce
the problem every single time, or I would have filed a bug report with
those exact reproducible steps.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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.

On 04.07.2010 08:51, TK Soh wrote:
> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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.

[Please do not mail me a copy of your followup]

Adrian Buehlmann <adrian@...> spake the secret code
<4C307AC3.3060008@...> thusly:

>That's exactly the kind of discussion I'm not at all interested to rehash.

I can appreciate that.  That's why I was asking for a way to read the
previous discussion.  Surely its archived somewhere?
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Sun, Jul 4, 2010 at 11:56 AM, Richard
<legalize+jeeves@...> wrote:
> [Please do not mail me a copy of your followup]

You might think about creating a gmail account for mailing list use.

> Adrian Buehlmann <adrian@...> spake the secret code
> <4C307AC3.3060008@...> thusly:
>
>>That's exactly the kind of discussion I'm not at all interested to rehash.
>
> I can appreciate that.  That's why I was asking for a way to read the
> previous discussion.  Surely its archived somewhere?

Most of this discussion was last summer, from April till May/June.

http://article.gmane.org/gmane.comp.version-control.mercurial.tortoisehg.devel/3617

-- 
Steve Borho

On Sun, Jul 4, 2010 at 12:12 PM, Adrian Buehlmann <adrian@...> wrote:
> On 04.07.2010 08:51, TK Soh wrote:
>> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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.

On Mon, Jul 5, 2010 at 1:03 AM, Steve Borho <steve@...> wrote:
> On Sun, Jul 4, 2010 at 11:56 AM, Richard
> <legalize+jeeves@...> wrote:
>> [Please do not mail me a copy of your followup]
>
> You might think about creating a gmail account for mailing list use.
>
>> Adrian Buehlmann <adrian@...> spake the secret code
>> <4C307AC3.3060008@...> thusly:
>>
>>>That's exactly the kind of discussion I'm not at all interested to rehash.
>>
>> I can appreciate that.  That's why I was asking for a way to read the
>> previous discussion.  Surely its archived somewhere?
>
> Most of this discussion was last summer, from April till May/June.
>
> http://article.gmane.org/gmane.comp.version-control.mercurial.tortoisehg.devel/3617

Ironically, that's discussion between Adrian and me, and somehow I've
forgotten most part of it, if not all. Well, after all, it's been a
long time ago, and I have a very bad long term memory ;-)

[Please do not mail me a copy of your followup]

Steve Borho <steve@...> spake the secret code
<AANLkTini4oueVmX0NYOcZci3hnB1VxfB0NVQa1pVCo_Q@...> thusly:

>You might think about creating a gmail account for mailing list use.

I'm not using a mailing list and I don't want an account on gmail, thanks.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

[Please do not mail me a copy of your followup]

Steve Borho <steve@...> spake the secret code
<AANLkTini4oueVmX0NYOcZci3hnB1VxfB0NVQa1pVCo_Q@...> thusly:

>Most of this discussion was last summer, from April till May/June.
>
>http://article.gmane.org/gmane.comp.version-control.mercurial.tortoisehg.devel/3617

Hmm... read through that whole thread and I don't see anything in it
talking about the hows/whys/whynots of overlay icons.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>

On Mon, Jul 5, 2010 at 11:41 AM, Richard
<legalize+jeeves@...> wrote:
> [Please do not mail me a copy of your followup]
>
> Steve Borho <steve@...> spake the secret code
> <AANLkTini4oueVmX0NYOcZci3hnB1VxfB0NVQa1pVCo_Q@...> thusly:
>
>>Most of this discussion was last summer, from April till May/June.
>>
>>http://article.gmane.org/gmane.comp.version-control.mercurial.tortoisehg.devel/3617
>
> Hmm... read through that whole thread and I don't see anything in it
> talking about the hows/whys/whynots of overlay icons.

That was just the start of the whole C++ shell extension development.
As I said, the discussion spanned a few months.  I'm not going to go
dig out all the links.

-- 
Steve Borho

On 05.07.2010 08:10, TK Soh wrote:
> On Sun, Jul 4, 2010 at 12:12 PM, Adrian Buehlmann <adrian@...> wrote:
>> On 04.07.2010 08:51, TK Soh wrote:
>>> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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).

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 <adrian@...> wrote:
>>> On 04.07.2010 08:51, TK Soh wrote:
>>>> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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.

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 <adrian@...> wrote:
>>>> On 04.07.2010 08:51, TK Soh wrote:
>>>>> On Sat, Jul 3, 2010 at 1:24 PM, Adrian Buehlmann <adrian@...> 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...

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
> 
> I didn't have much time to debug, but below is the debug trace from
> debugview with the actions (I captured the screen but didn't attach in
> this post since it will probably get filtered by mailman):
> - open, edit and save doc\hgignore.5.txt -> icon changed to Modified
> - undo edit and save  doc\hgignore.5.txt -> icon stays as Modified
> - open, edit and save doc\gendoc.py -> icon changed to Modified
> (hgignore.5.txt  icon stays as Modified)
> - wait a few minutes - both icons remains as Modified
> - close both files on editor
> - open, undo edit and save doc\gendoc.py - both icons remains as Modified
> - wait ~30 minutes - both icons remains as Modified
> - run "Update Icons" menu - both icons switch to Unchanged
> 
> 
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\hgignore.5.txt):
> hgroot = 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read(c:\hg-stable): done. 0 entries
> read. noicons_ = 0
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> [4720] [THGx86] [C] HgQueryDirstate: relbase = 'doc'
> [4720] [THGx86] [C] HgQueryDirstate: basedir_status = C
> [4720] [THGx86] [C] HgQueryDirstate: calling Thgstatus::update
> [4720] [THGx86] Thgstatus::update: sending 'update|c:\hg-stable' to
> \\.\pipe\TortoiseHgRpcServer-bc0c27107423-tksoh
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\hgignore.5.txt):
> hgroot = 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read(c:\hg-stable): done. 1 entries
> read. noicons_ = 0
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> [4720] [THGx86] [C] HgQueryDirstate: relbase = 'doc'
> [4720] [THGx86] [C] HgQueryDirstate: basedir_status = M
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\gendoc.py): hgroot =
> 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read(c:\hg-stable): done. 1 entries
> read. noicons_ = 0
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> [4720] [THGx86] [C] HgQueryDirstate: relbase = 'doc'
> [4720] [THGx86] [C] HgQueryDirstate: basedir_status = M
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\gendoc.py): hgroot =
> 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read(c:\hg-stable): done. 1 entries
> read. noicons_ = 0
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> [4720] [THGx86] [C] HgQueryDirstate: relbase = 'doc'
> [4720] [THGx86] [C] HgQueryDirstate: basedir_status = M
> 
> ==== run Update Icons ====
> [4720] [THGx86] CShellExtCMenu::InvokeCommand
> [4720] [THGx86] CShellExtCMenu::InvokeCommand: idCmd = 16
> [4720] [THGx86] Thgstatus::update: sending 'remove|C:\hg-stable\doc'
> to \\.\pipe\TortoiseHgRpcServer-bc0c27107423-tksoh
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\common.txt): hgroot =
> 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read: can't open 'c:\hg-stable\.hg\thgstatus'
> [4720] [THGx86] Thgstatus::update: sending 'update|c:\hg-stable\doc'
> to \\.\pipe\TortoiseHgRpcServer-bc0c27107423-tksoh
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> [4720] [THGx86] Dirstatecache::get: refreshing c:\hg-stable
> [4720] [THGx86] Dirstatecache::get: read done in 16 ticks, 2 repos in cache
> [4720] [THGx86] Dirstatecache::get: calling Thgstatus::update
> [4720] [THGx86] Thgstatus::update: sending 'update|c:\hg-stable\doc'
> to \\.\pipe\TortoiseHgRpcServer-bc0c27107423-tksoh
> [4720] [THGx86] [C] findHgRoot(c:\hg-stable\doc\common.txt): hgroot =
> 'c:\hg-stable' (found repo)
> [4720] [THGx86] DirectoryStatus::read(c:\hg-stable): done. 0 entries
> read. noicons_ = 0
> [4720] [THGx86] Dirstatecache::get: lstat(c:\hg-stable\.hg\dirstate) ok
> 

I've pushed

http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb

to stable or this.

Please try a next stable nightly (as soon as there appears one).

On 08.07.2010 00:26, Adrian Buehlmann wrote:
> I've pushed
> 
> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
> 
> to stable or this.

Typo. Should be: "... for this."

> Please try a next stable nightly (as soon as there appears one).

On Wed, Jul 7, 2010 at 5:58 PM, Adrian Buehlmann <adrian@...> wrote:
> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>> I've pushed
>>
>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>
>> to stable or this.
>
> Typo. Should be: "... for this."

Thanks Adrian.

The nightly builds are currently hung up waiting for hg-crew to be
pulled into main.  Hopefully this will happen in the next day or so.

-- 
Steve Borho

On Thu, Jul 8, 2010 at 6:58 AM, Adrian Buehlmann <adrian@...> wrote:
> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>> I've pushed
>>
>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>
>> to stable or this.
>
> Typo. Should be: "... for this."
>
>> Please try a next stable nightly (as soon as there appears one).

Appreciate your spending time on this. Will try it as soon as the
nightly build it available,

On Thu, Jul 8, 2010 at 1:19 AM, TK Soh <teekaysoh@...> wrote:
> On Thu, Jul 8, 2010 at 6:58 AM, Adrian Buehlmann <adrian@...> wrote:
>> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>>> I've pushed
>>>
>>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>>
>>> to stable or this.
>>
>> Typo. Should be: "... for this."
>>
>>> Please try a next stable nightly (as soon as there appears one).
>
> Appreciate your spending time on this. Will try it as soon as the
> nightly build it available,

Matt pulled from crew a half hour ago, new nightly builds are up.

Stable branch only for the near future.

-- 
Steve Borho

On Thu, Jul 8, 2010 at 3:59 PM, Steve Borho <steve@...> wrote:
> On Thu, Jul 8, 2010 at 1:19 AM, TK Soh <teekaysoh@...> wrote:
>> On Thu, Jul 8, 2010 at 6:58 AM, Adrian Buehlmann <adrian@...> wrote:
>>> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>>>> I've pushed
>>>>
>>>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>>>
>>>> to stable or this.
>>>
>>> Typo. Should be: "... for this."
>>>
>>>> Please try a next stable nightly (as soon as there appears one).
>>
>> Appreciate your spending time on this. Will try it as soon as the
>> nightly build it available,
>
> Matt pulled from crew a half hour ago, new nightly builds are up.
>
> Stable branch only for the near future.

I can see three installers dated 11 hours ago (as of writing),
including mercurial-stable-1.6.1015.msi, Does it include Adrian's
change, or I need to grab the one with really long name?

On Thu, Jul 8, 2010 at 9:38 PM, TK Soh <teekaysoh@...> wrote:
> On Thu, Jul 8, 2010 at 3:59 PM, Steve Borho <steve@...> wrote:
>> On Thu, Jul 8, 2010 at 1:19 AM, TK Soh <teekaysoh@...> wrote:
>>> On Thu, Jul 8, 2010 at 6:58 AM, Adrian Buehlmann <adrian@...> wrote:
>>>> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>>>>> I've pushed
>>>>>
>>>>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>>>>
>>>>> to stable or this.
>>>>
>>>> Typo. Should be: "... for this."
>>>>
>>>>> Please try a next stable nightly (as soon as there appears one).
>>>
>>> Appreciate your spending time on this. Will try it as soon as the
>>> nightly build it available,
>>
>> Matt pulled from crew a half hour ago, new nightly builds are up.
>>
>> Stable branch only for the near future.
>
> I can see three installers dated 11 hours ago (as of writing),
> including mercurial-stable-1.6.1015.msi, Does it include Adrian's
> change, or I need to grab the one with really long name?
>

This page explains them all:

http://bitbucket.org/tortoisehg/thg-winbuild/wiki/Home

-- 
Steve Borho

On Fri, Jul 9, 2010 at 3:29 AM, Steve Borho <steve@...> wrote:
> On Thu, Jul 8, 2010 at 9:38 PM, TK Soh <teekaysoh@...> wrote:
>> On Thu, Jul 8, 2010 at 3:59 PM, Steve Borho <steve@...> wrote:
>>> On Thu, Jul 8, 2010 at 1:19 AM, TK Soh <teekaysoh@...> wrote:
>>>> On Thu, Jul 8, 2010 at 6:58 AM, Adrian Buehlmann <adrian@...> wrote:
>>>>> On 08.07.2010 00:26, Adrian Buehlmann wrote:
>>>>>> I've pushed
>>>>>>
>>>>>> http://bitbucket.org/tortoisehg/stable/changeset/69ba8d0380eb
>>>>>>
>>>>>> to stable or this.
>>>>>
>>>>> Typo. Should be: "... for this."
>>>>>
>>>>>> Please try a next stable nightly (as soon as there appears one).
>>>>
>>>> Appreciate your spending time on this. Will try it as soon as the
>>>> nightly build it available,
>>>
>>> Matt pulled from crew a half hour ago, new nightly builds are up.
>>>
>>> Stable branch only for the near future.
>>
>> I can see three installers dated 11 hours ago (as of writing),
>> including mercurial-stable-1.6.1015.msi, Does it include Adrian's
>> change, or I need to grab the one with really long name?
>>
>
> This page explains them all:
>
> http://bitbucket.org/tortoisehg/thg-winbuild/wiki/Home

Thanks.

On 7/3/2010 6:24 AM, Adrian Buehlmann wrote:
>
> Hello Tk, it's been a while since you posted here :-)
>
> 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).
>
> 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).
>
> 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).
>

I haven't looked in detail how TortoiseHg handles this, but...
Anything useful (and applicable) in how git handles these?

http://www.kernel.org/pub/software/scm/git/docs/technical/racy-git.txt