Check in undo check out and save newest version in _sgbak

Tri · Post by **Tri** » Tue Feb 15, 2005 3:52 pm

Client 2.06.

I have checked out and modified File1, File2.

I checked in both at the same time from within VS2003. Both files has the blue lock icon after this operation.

File1 changes are ignored like if it was an "undo check out". File2 was correctly checkd out. Fortunately the changed I made in File1 was saved in _sgbak.

What was the reason for the check-in of File1 to fail?

dan · Post by **dan** » Tue Feb 15, 2005 4:21 pm

Did the output window in Visual Studio report any problems?

Is this something you can reproduce?

Any further detailed info you can provide would help localize this.

Tri · Post by **Tri** » Wed Feb 16, 2005 9:48 am

VS2003 output screen didn't report any unusual message. Can't reproduce the issue. Two other developers also experienced this problem.

Can you suggest a diagnostic procedure?

dan · Post by **dan** » Wed Feb 16, 2005 10:00 am

You can try to turn on logging in the client (see http://support.sourcegear.com/viewtopic.php?t=2146) and if it happens again, send us the log. There is also additional logging in the 3.0 version of Vault, and since you are on gold support, it should be a free upgrade.

Another thing to try is to keep the Vault GUI client up and see what the actual status of the files are according to the GUI client before they are checked in. If the status is "Unknown" that might explain what is happening. You'll need to know what the state is before the checkin though to get decent info on what is happening.

Tri · Post by **Tri** » Thu Feb 17, 2005 8:40 am

Does it have anything to do with shared project?

We have had repeatedly the check in issue yesterday (check in is said OK, but new file is saved in _sgbak, and in Vault, the check out is undone. Immediately after that, in VS2003, the current version is replaced by the previous version in Vault).

The problem only happen on files within a shared project. ProjectC is shared by ProjectA and ProjectB. Currently developers only work on ProjectA. There is exclusive lock when file is checked out.

I've played around with the client log you suggested. The log file increases in size quite quickly. Can you please suggest what are the log class to enable in VaultGUIClient.exe.config to gather enough for the issue above?

My current setting is:
<add key="classesToLog" value="createrequest,commit,get,ide,updateknownchanges,upload" />

But I keep gathering thousands of lines <checkoutlist> which are related to files that have nothing to do with what I am working on.

dan · Post by **dan** » Thu Feb 17, 2005 8:59 am

If you can reproduce it, find out what the status of the file is in the GUI client just prior to the checkin.

Tri · Post by **Tri** » Thu Feb 17, 2005 9:25 am

dan wrote:Another thing to try is to keep the Vault GUI client up and see what the actual status of the files are according to the GUI client before they are checked in. If the status is "Unknown" that might explain what is happening. You'll need to know what the state is before the checkin though to get decent info on what is happening.

We'll try this later, for now, let's assume that the status is unknown.
If the file is exclusively locked at check out time, why would it become suddenly unknown? Especially when we are certain that the developer is the only one person who work on this file.

dan · Post by **dan** » Thu Feb 17, 2005 9:44 am

It might have something to do with Visual Studio being confused about shared folders? I would check the working folders associations and make sure they are what you expect them to be. Often Unknowns come about because working folders are switched.

If you can reliably reproduce this, go through the sequence of events and look at the file status in the GUI client the whole time to see when it changes to Unknown