Bug - does not show "Locked" icon when file is locked.
Dylan Reynolds
file. I have locked the file in the same check out directory that I am
trying to observe the locked icon overlay (as in I am not trying to see
a lock from a different checkout folder). The file I am locking has the
property svn:needs-lock enabled with a *. This makes the readonly (grey
tick) icon overlay act on the file. However, when I then lock the file
to use it, the icon overlay first of all disappears so the file looks
like a normal file. When you manually refresh the windows explorer (or
go up a level and return) the file has a normal(green tick) icon
overlay. I believe the file should show the locked icon overlay. If
you then release the lock, the file will return to having no icon
overlay, until once again you refresh the explorer and it will return to
being the readonly icon overlay.
As mentioned above another related issue seems to be that when you first
lock the readonly file the icon overlay disappears - leaving what looks
like a normal file.
In summary it seems there are two problems here that may be related.
The first is that the locked icon overlay is not being used when I
believe it should be. The second is that the when the readonly icon
overlay is changed from, or changed to, it does not seem to
automatically refresh windows explorer.
I have attempted to search through all bug fixes, mailing lists, task
tracker etc... to ensure that this bug has not yet been fixed.
I am running Vista, and:
TortoiseSVN 1.5.3, Build 13783 - 32 Bit , 2008/08/30 20:59:46
Subversion 1.5.2,
apr 1.2.12
apr-utils 1.2.12
berkeley db 4.4.20
neon 0.28.3
OpenSSL 0.9.8g 19 Oct 2007
zlib 1.2.3
Sorry but I did not want to update to a nightly build to see if the bug
was still there, but as you can see I do have the latest stable release
build.
Kind Regards,
Dylan Reynolds
---------------------------------------------------------------------
To unsubscribe, e-mail: users-un...@tortoisesvn.tigris.org
For additional commands, e-mail: users...@tortoisesvn.tigris.org
Stefan Küng
http://tortoisesvn.tigris.org/faq.html#ovlnotall
"Locked is only loaded if there are less than 13 overlays already
loaded. It falls back to Normal if there are not enough slots."
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Dylan Reynolds
Sorry I really did try to see if this was a bug or not or if it was
something I was doing wrong. Thanks for the quick reply and keep up the
excellent work with TSVN. Is there any merit to the other problem I was
having? Or is this directly related to not having overlays so the
refresh doesn't work properly? Also is there any safe way I can change
the overlays windows/TSVN is using so that I can use the locked overlay
(my application will require locking and it will be very helpful to have
this overlay working)?
Cheers Dylan
Stefan Küng
> Thanks Stefan,
>
> Sorry I really did try to see if this was a bug or not or if it was
> something I was doing wrong. Thanks for the quick reply and keep up the
> excellent work with TSVN. Is there any merit to the other problem I was
> having? Or is this directly related to not having overlays so the
> refresh doesn't work properly? Also is there any safe way I can change
> the overlays windows/TSVN is using so that I can use the locked overlay
> (my application will require locking and it will be very helpful to have
> this overlay working)?
* TSVN properly sends refresh messages to the Explorer. If you have to
manually hit F5 to refresh the overlay, then there's nothing TSVN can
do about that.
* you can manually remove overlay handlers which you think you won't
need:
HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers
lists all installed handlers. Just remove the key(s) of the handler(s)
you don't need (maybe create a backup first).
Dylan Reynolds
Stefan Küng wrote:
Dylan Reynolds wrote:Thanks Stefan, Sorry I really did try to see if this was a bug or not or if it was something I was doing wrong. Thanks for the quick reply and keep up the excellent work with TSVN. Is there any merit to the other problem I was having? Or is this directly related to not having overlays so the refresh doesn't work properly? Also is there any safe way I can change the overlays windows/TSVN is using so that I can use the locked overlay (my application will require locking and it will be very helpful to have this overlay working)?* TSVN properly sends refresh messages to the Explorer. If you have to manually hit F5 to refresh the overlay, then there's nothing TSVN can do about that. * you can manually remove overlay handlers which you think you won't need: HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers lists all installed handlers. Just remove the key(s) of the handler(s) you don't need (maybe create a backup first). Stefan
Stefan Küng
> Cheers, I got the overlays working. I would not so easily discount the
> refresh problem. This is because all other changes I make - such as
> adding new folders/files, modifying files etc... make instant split
> second changes to the overlays (they automatically refresh). It is only
> the lock and unlock process which does not have proper refresh
> operation. Perhaps this is unavoidable and if so I really don't mind
> hitting F5. I just thought that if everything else happens instantly
> during normal operation then perhaps this should to. Thanks for your
> help. Much appreciated.
I've explained this before, but I can't find it in the archives right
now. So again:
The explorer sometimes ignores refresh notifications. It does this
because some applications sent way too many notifications and would
cause problems for the Explorer. So now, the explorer sometimes ignores
the notifications. While experimenting, I found that the explorer itself
checks the files/folders for modifications it receives a notification.
If it finds a modification (e.g., last-write-time changes), it accepts
the notification and updates the icon overlays. It then rejects the next
notifications for some time after that (because it already updated the
overlays).
But: if it can't find a modification to the files/folder it receives a
refresh notification for, it doesn't update the overlays.
Now: a change in a subversion status does not necessarily mean that the
file has also changed. For example, if you add a file, the file itself
doesn't change but only an entry inside the .svn folder changes to mark
that file as 'added'. In that case, the explorer ignores the
notification and you have to press F5 to force the refresh.
In your case, it's a little bit different: you have the svn:needs-lock
set. When you get a lock, Subversion first removes the 'readonly'
attribute from the file, then changes the entries file inside the .svn
folder to mark the file as being locked. Only after that happens, TSVN
can send the refresh notification to the explorer.
Since the explorer also constantly monitors the current folder for
modifications (you can check that: if you run a batch file which creates
new files, explorer will show them without you having to press F5), it
detects that the readonly attribute was removed and refreshes the view.
If it does that before TSVN sends the notification, then the
notification from TSVN will be ignored because it will be sent within
the refresh-timeout (see my explanation above).
So, yes: for other commands, the explorer refreshes the overlays
correctly most of the time, but for add/lock and some others, it most of
the time does not. But as I said: there's nothing we can do about that
in TSVN.
Simon Large
> In your case, it's a little bit different: you have the svn:needs-lock
> set. When you get a lock, Subversion first removes the 'readonly'
> attribute from the file, then changes the entries file inside the .svn
> folder to mark the file as being locked. Only after that happens, TSVN
> can send the refresh notification to the explorer.
> Since the explorer also constantly monitors the current folder for
> modifications (you can check that: if you run a batch file which creates
> new files, explorer will show them without you having to press F5), it
> detects that the readonly attribute was removed and refreshes the view.
> If it does that before TSVN sends the notification, then the
> notification from TSVN will be ignored because it will be sent within
> the refresh-timeout (see my explanation above).
Does this warrant a request to change the subversion code to update
the entries file first and then change the read-only status?
Simon
--
: ___
: oo // \\ "De Chelonian Mobile"
: (_,\/ \_/ \ TortoiseSVN
: \ \_/_\_/> The coolest Interface to (Sub)Version Control
: /_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
Stefan Küng
> 2008/9/19 Stefan Küng <torto...@gmail.com>:
>> In your case, it's a little bit different: you have the svn:needs-lock
>> set. When you get a lock, Subversion first removes the 'readonly'
>> attribute from the file, then changes the entries file inside the .svn
>> folder to mark the file as being locked. Only after that happens, TSVN
>> can send the refresh notification to the explorer.
>> Since the explorer also constantly monitors the current folder for
>> modifications (you can check that: if you run a batch file which creates
>> new files, explorer will show them without you having to press F5), it
>> detects that the readonly attribute was removed and refreshes the view.
>> If it does that before TSVN sends the notification, then the
>> notification from TSVN will be ignored because it will be sent within
>> the refresh-timeout (see my explanation above).
>
> Does this warrant a request to change the subversion code to update
> the entries file first and then change the read-only status?
No, not for such a non-issue. All you have to do is hit F5 to refresh
the explorer view, so I don't think it is a big deal.
Stefan