TortoiseSVN: What causes the grey checkmark?

Question

Let me start by explaining our set-up:

I am working with some contractors. They are using Visual Source Safe for source control and our company is using Subversion. Every few days they preform a checkin to our repository by doing the following steps:

1. Checkout from our repository (they're the only ones working on it so this doesn't actually do anything)
2. Copy into the directory all the application files
3. Commit back

Its a horrible process and we plan to address it in the next iteration but it works. Except that sometimes it doesn't. Sometimes after they do the commit some of the files have a gray checkmark overlay.

I am not sure what this means. Googling around implies it might have something to do with locking but nobody is explicitly locking anything! The files seem to get committed, but they are missing when I do a check out. I am sure that I am missing something.

Can anyone explain whats gong on and how to fix it?

Answer 1

These are file which have the svn:needs-lock property set. To edit these files you first have to lock them.

Here's the explanation from TortoiseSVN's help file:

If you have set the svn:needs-lock property on a file, Subversion makes that file read-only until you get a lock on that file. Such files have this overlay to indicate that you have to get a lock first before you can edit that file.

This is usually used with binary files (images, word documents, etc.) that can not easily be merged when edited by several persons. The lock prevents that the file can be edited by more than one person at a time.

If you want to remove the svn:needs-lock property, then right-click the file, select TortoiseSVN -> Properties and delete the property.

Update: what can cause a file to have the svn:needs-lock property:

• either it was explicitly set by someone
• or you have some rules in the subversion config file (TortoiseSVN -> Settings -> Edit subversion configuration file). Check the [auto-props] section of that file. For example, we automatically set the needs-lock property on all MS-Office files, by adding the corresponding file-extensions to the [auto-props] section of the subversion config file.

Answer 2

from here:

If you have set the svn:needs-lock property on a file, Subversion makes that file ReadOnly until you get a lock on that file. Read-only files have this overlay to indicate that you have to get a lock first before you can edit that file.

We don't use the needs-lock stuff here, so I can't really explain more. It's a start though.

Edit: Since they are using VSS, the files will have the read-only attribute set when they are not checked out. TortoiseSVN may be interpreting this as having the needs-lock set.

Answer 3

I googled it and apparently the file is locked. http://tortoisesvn.net/node/138

Answer 4

Are those binary files? If so it means the files are lock exclusive on the server, so that no one can check them out simultaneously.

Answer 5

This might help?

http://www.nabble.com/Document-locked,-won%27t-release-td15162692.html

the read only attribute was set.

They need to correct that on their side probably.

and definitely force them to use your version control system

Answer 6

If you're going to continue with this terrible plan, might I suggestion you investigate the svn_load_dirs script? It's used for applying changes from a non-versioned directory hierarchy to a SVN repo. In this case, your non-versioned files would actually be from VSS, but that doesn't count as versioned for this purpose. Basically, it noticed what was added and what was removed, gives you an opportunity to tell it that some of those add/removes were actually renames/moves, and then it applies the changes to your repo. It's way, way better than just pasting files onto a working copy, as the latter approach will not properly handle add/removed files or directories.

To answer your original question, the grey checkmark means the file is read only. This is usually only encountered when the file needs to be locked in order to write to it, but I'm pretty sure it will mark any read only file with the grey checkmark, not just ones that have svn:needs-lock set on it. As for why the files wouldn't show up when you check out, that's almost certainly because they were never checked in... if they're in the server, they'll show up in your working copy when you update/checkout (or it will give you a clear error message about something obstructing them).

Answer 7

To show you the file and folder icon overlays TortoiseSVN must fetch the status each time you open such a folder in the explorer. This usually takes a fraction of a second, but can take much longer if you have either a slow hard disk or a very big directory. Here are a few things to watch out for: Network drives can be very slow to respond, so you may have to turn off icon overlays for such drives. However, the caching scheme usually makes it workable. Whenever the last modified time of a file changed, TortoiseSVN needs to do a complete diff (!) of that file to find out if it has changed. If you often change a file, undo the changes and save the file again you'll encounter a slowdown in browsing. You can fix that condition by doing a Cleanup of your working copy folders. There are several Virus scanners around that interfere with TortoiseSVN. Most of the time they lock files inside the .svn Status directory, which can cause TortoiseSVN to hang or to become very slow. Sometimes you might even get an Access Denied error. Try to configure your virus scanner so that it ignores .svn directories. If you're working on Windows XP then you can also disable the zipfolders. This will also increase the browsing speed. 1.Select Run from the start menu 2.Type regsvr32 /u %windir%\system32\zipfldr.dll at the prompt and click ok 3.The change will take effect immediately, but you may have to restart Windows for all traces of the built-in ZIP support to disappear. If, at any time, you wish to re-enable Windows XP's built-in ZIP support, just follow these steps: 4.Select Run from the start menu 5.Type regsvr32 %windir%\system32\zipfldr.dll at the prompt and click ok 6.The change will take effect immediately, but you may have to restart Windows for all traces of the built-in ZIP support to be available. Check your system for spyware, policy enforcement software, or local search engines (like Google desktop). Those can all interfere with normal use quite effectively.