Stefan Küng wrote:
> Arne Moor wrote:
> > instead of changing the overlay on a changed file, the icon was draw
> > over the .svn folder. The folder was freshly checked out, than one
> > file was changed and saved, the icon was drawn wrong, refreshed
> > explorer via F5, the icon was drawn for the right file. Reverted
> > multiple times and retried, always the same behavior.
> >
> > See the attached screen shot.
>
> This is a 'bug' in the shell (explorer) itself. TSVN always tells the
> shell the correct overlay (and it *never* draws an overlay for the .svn
> folder). The problem here is a race condition:
> * shell asks for overlay
> * TSVN returns the overlay index
For the uninitiated, what is an "overlay index" ?
The index of a file in it's folder, the index of a piece of graphics
in a table / larger image or something internal in TSVNCache?
> * before the shell can draw the overlay, an update notification is sent
> (either by the TSVN cache or another app)
> * the update notification forces the shell to reload the contents of
> the shown folder
> * the overlays are drawn in the 'old' order, even if the reload changed
> the file order shown.
If "overlay index" means the index of a file in it's folder, that should
not have changed; Arne modified an existing file.
> We could reduce those wrong overlays by not sending shell notifications
> every time we detect a status change. But then people will complain that
> the overlays don't update after a commit/update/...
FWIW, I agree that it's a small problem - F5 fixes it. Might be worth to
FAQ the above under ".svn folder gets overlay" or some such, I think
you've given this answer before.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Dec 27 10:02:10 2005