Stefan Küng wrote:
> Peter McNab wrote:
>
>> Yes, I tried again and all has worked normal too (after the once only
>> cache restart).
>>
>> What I thought I should do is more precisely describe how the problem
>> manifested itself because there is a clue embedded therein.
>>
>> What I had been doing at the time when I noticed the problem was
>> going through various project folders deleting auto generated files
>> before committing some project changes.
>> It was on navigation back out of a folder high in the directory
>> structure that a folder containing correctly displayed changed files
>> reverted to the incorrect (unmodified) icon state.
>
>
> But the files in it were still shown as modified?
Yes, navigating in and out of all of the folder always displayed the
modified files icons correctly.
>
>> The incorrectly displayed folder was accompanied two others,
>> correctly displayed, one showing modified the other unmodified.
>> Reversing out of that folder back to the branched level revealed an
>> unmodified status whereas it should have been modified..
>> Reversing further out showed the unmodified status had propagated
>> backwards to the project root.
>> I had the whole project checked out, not just a high level WC.
>> Once the error had occurred, no amount of navigating and F5-ing would
>> fix the problem.
>> I don't use the two pane view in Explorer.
>>
>> So, it appears that the unupdated status has propagated back towards
>> the WC root regardless of there being another folder in the directory
>> structure correctly displaying the modified status.
>
>
Just confirming, where I said "So, it appears that the unupdated status
has propagated back..." means that green appeared where red had existed.
> Yes, that's how it works.
That's not what I would expect.
Although I don't know the reason why one folder suddenly *reverted*
from displaying modified to displaying unmodified, the fact that the
unmodified status trickled down out of a folder still containing a
modified folder had me perplexed.
> But after propagating the status up through the tree, the cache crawls
> all those folders again and will eventually update the overlays again.
> Of course, depending on the size of your working copy, this can take a
> while (and during that time, F5 won't help because that simply
> triggers a new crawl).
>
> Stefan
>
It took some time after all that to produce a series of screen shots of
the situation, so there was plenty of time for the cache to catch up. (I
later blew them away by accident).
Am I providing anything useful or just black dots?
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Nov 4 14:18:10 2005