Hi Stefan.
Stefan Küng wrote:
> Peter McNab wrote:
>
>> 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.
>
>
> Yes. The cache works like this:
> if a change in an item is detected, it fetches the status of that item
> again. If the status of that item changed, the changed status is
> propagated upwards in the tree. Once it reaches the top of the wc, the
> crawler kicks in and recursively fetches the status again, to
> 'correct' maybe wrong statuses.
>
Attached is a text mock up of the folder structure giving a before and
after view of the icon status.
It is with your above statement in mind that I produced the diagram to
explore possible problems.
"If the status of that item changed, the changed status is propagated
upwards in the tree".
When "that item" is a file and it's status has gone from modified to
unmodified, does the code not check first to see if there are any
overriding factors, like other modified files or folders at within the
current folder before propagating an unmodified status back up the tree?
Similarly, if "that item" is a folder does the code not also check first
to see if there are any overriding factors...blah blah as above?
"Once it reaches the top of the wc, the crawler kicks in and recursively
fetches the status again, to 'correct' maybe wrong statuses"
The question raised then is why does it not eventually troll to the
modified file in the MLD folder, find it is modified and then fix up the
cache status back up the tree. I guess that Explorer might need to
initiate a view refresh but I had spent a while collecting screen shots
and was navigating back and forth to double check there was a problem
which would have kicked in Explorer's refresh.
Is there any chance that the recursive folder trolling process has a
flaw with methodically misses one or more folders or files? On the
surface, thats what it looks like on the basis of the quoted statement.
I'm not questioning *your* integrity here, of which there is no doubt,
but just the possibility that the code has a loophole somewhere which
lets a modified status file go un-noticed for so long.
Peter
Icon status before commit and before clearing unused files from /MLD folder and navigating back to /examples folder.
wcroot(M)/Externals(U)
/Trunk(U)
/Tags(U)
/Branches/B1(U)
/B2(U)
/B3(M)/Trunk(U)/src(M)
/B4(U) /tests(U)
/B5(U) /examples(M)/ex1(U)
/ex2(U)
/MLD(M):file1(U)
:file2(M)
:file3..n(U)
Icon status thereafter regardless of reboot, F5-ing, navigating into and out of modified and unmodified status folders and waiting.
wcroot(U)/Externals(U)
/Trunk(U)
/Tags(U)
/Branches/B1(U)
/B2(U)
/B3(U)/Trunk(U)/src(M)--------------:file1(U)
/B4(U) /tests(U) :file2(M)
/B5(U) /examples(U)/ex1(U) :file3..n(U)
/ex2(U)
/MLD(U)--:file1(U)
:file2(M)
:file3..n(U)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Sat Nov 5 03:39:22 2005