Cannot check out because file is already checked out

Tri · Post by **Tri** » Mon Jun 06, 2005 9:57 am

Client + Server 3.07

A user attempted to check out a file. The operation is completed but the file is NOT checked out. When the user tries to check out again, Vault Client returns a msg saying "cannot check out because file ABC.txt is already checked out". The only solution we know so far is to use Admin Tool to undo the check out.

We have had this scenarios from time to time. But the issue cannot be reproduced. Here is what had happenned today:

- User has edited 2 files (in two different subfolders). These files were checked in and the user has overriden the Read-Only file attribute to edit them.

- When connected to Vault Server, the files are seen as Renegade.

- The user attempted a Check Out each file. With "Modified Local File" option set to "Do not overwrite/Merge later".

- The issue described above occured on both files (files checked out but are seen as checked in, even if Vault Client is refreshed, exited / restarted several times).

NOTES: sometime ago, I even asked the user to delete all CacheMember files and the _sgvault folder. It didn't help. The only cure is to use Admin Tool to undo the check out.

QUESTION: What is the reason for Vault Client to ignore the real check out status of a file?

lbauer · Post by **lbauer** » Mon Jun 06, 2005 1:58 pm

Are you seeing this in the GUI client or IDE client (VS.NET)?

Is the user using CVS or VSS mode? Compare the settings in Tools->Options->Concurrent Development Style.

How do you know the files are checked out? Do they appear checked out on another user's machine?

Does the pending change set show the file is checked out?

Tri · Post by **Tri** » Tue Jun 07, 2005 7:33 am

lbauer wrote:Are you seeing this in the GUI client or IDE client (VS.NET)?

In Vault Client 3.07

Is the user using CVS or VSS mode? Compare the settings in Tools->Options->Concurrent Development Style.

VSS mode

How do you know the files are checked out? Do they appear checked out on another user's machine?

Admin Tool, Undo check out. The files are there. I selected them, Undo checkout and the user could check them out again.

Does the pending change set show the file is checked out?

No, but behind the scene, the files WERE really checked ou by the user (as seen in Admin Tool).

Post by **jclausius** » Tue Jun 07, 2005 8:24 am

Tri:

A couple of more questions.

If you try to checkout the same file, does it succeed for you?

If you log in as that particular user on your machine does the checkout get updated on your client?

Does this repository use folder security? If so, if you temporarily disable it, and have the user re-try the checkout does that succeed?

Tri · Post by **Tri** » Tue Jun 07, 2005 8:52 am

jclausius wrote:If you try to checkout the same file, does it succeed for you?

Didn't try. Will think about this next time. But I guess that Vault client will refuse to check out b/c it has been checkedout by someone else.

If you log in as that particular user on your machine does the checkout get updated on your client?

Didn't try and cannot try now because this issue this not easily reproducible.

Does this repository use folder security? If so, if you temporarily disable it, and have the user re-try the checkout does that succeed?

Yes, the repository use folder security.

I will definitely try all your suggestions next time if this happen again.

Post by **jclausius** » Tue Jun 07, 2005 8:57 am

Tri wrote:
jclausius wrote:If you try to checkout the same file, does it succeed for you?
Didn't try. Will think about this next time. But I guess that Vault client will refuse to check out b/c it has been checkedout by someone else.

Is the user exclusively checking out the file? If not, you should be able to check out the file.

Can you also verify the server/client as Vault 3.0.7? (Just want to make sure).

Anything else about the file you can tell us? Shared File? Binary File? etc.

Tri · Post by **Tri** » Mon Jun 13, 2005 2:23 pm

jclausius wrote:Is the user exclusively checking out the file? If not, you should be able to check out the file.

It happened again today for another user. We always use exclusive check out. No one can check out the file (we have tried), not even the author (and he didn't change anything in his Vault client, Restarting Vault Client didn't help). The only cure is Admin Tool, Undo check out.

Can you also verify the server/client as Vault 3.0.7? (Just want to make sure).

Server 3.07, Client 3.06 (for the user having the problem today)

Anything else about the file you can tell us? Shared File? Binary File? etc.

Exclusive lock. Files are Global.asax, Global.asax.cs, Global.asax.resx.

Post by **jclausius** » Mon Jun 13, 2005 3:23 pm

Can you make a backup of the database ASAP? I'm hoping to "capture" the state of the checkout lists to help see if there is something in the repository that may give an indication of a problem.

Tri · Post by **Tri** » Mon Jun 13, 2005 4:10 pm

jclausius wrote:Can you make a backup of the database ASAP? I'm hoping to "capture" the state of the checkout lists to help see if there is something in the repository that may give an indication of a problem.

Too late? I have done Undo CheckOut un the Admin Tool. I can do only backup later tonight. I'll think of that next time (this error occurs once every 1 or 2 weeks).

Post by **jclausius** » Mon Jun 13, 2005 9:11 pm

If you can capture the database as soon as you hear of the problem, it might help us track down the problem.

Is it safe to assume you run with folder security enabled, and this user has been denied part of the repository?

Tri · Post by **Tri** » Tue Jun 14, 2005 12:00 pm

jclausius wrote:Is it safe to assume you run with folder security enabled, and this user has been denied part of the repository?

- Folder security enabled.
- User is member of a group
- This group doesn't have any permission on a few folders in the repository.
- The files involved are located in a folder where the group has full permission.

Post by **jclausius** » Tue Jun 14, 2005 12:43 pm

OK. As I mentioned, we're investigating to find the particulars. Having a database in this state would help the investigation.

Tri · Post by **Tri** » Wed Jun 15, 2005 10:03 am

It happened again (Client 3.06, Server 3.07)

- UserX has checked out (from within VS2003) 10 files in 2 projects (*.cs & *.config). VS icon showed files as checked out.

- When code update is done, UserX checked in 4 files first (from within VS2003).

- It took long time, VS seems to hang. UserX close VS and use Vault Client to check them in. The 4 files, and strangely enough, also all the other files initially checked by UserX showed up as checked in with Renegade status.

- From within Vault client, UserX attempted to check out the 4 files in order to check them in. Error msg: "You already have these file check out".

- Your advice #1: UserX opened Vault Client on another computer, logged in as UserX (this computer has Vault 3.07 installed instead of 3.06). The files are seen as checked out and UserX can undo the checkout (just for 1 file to test the idea). UserX returned to his computer and can check in the file.

I don't know if it is the client version, but I think the real help was may be the use of another computer.

- Your advice #2: disable the Folder security. UserX (working on his usual computer) refreshed files. All troubled files now are seen as checked out with Edited status. (i.e. disable Folder security has really fixed the problem). UserX could check in all files. After that I re-enable Folder security.

Hope you can spot anything useful for your investigation.

Post by **jclausius** » Wed Jun 15, 2005 10:10 am

Tri:

Did you capture the database backup? Is there any chance I can get a look at it?

Also, can I also get a look at your server's sgvault.log file?

Post by **jclausius** » Wed Jun 15, 2005 10:35 am

Tri:

Can you find out of the users who've reported this, does this only happen when they kill VS.Net during a commit operation? Or has it happened through a normal VS.Net session.

Also, it would help if you know this ALWAYS happens with VS.Net / Vault integrated client, the Vault GUI client, or both.