Checkin fails regularily

atlaste · Post by **atlaste** » Wed Nov 21, 2007 4:10 am

Hi,

We work daily with Vault, integrated in Visual studio professional 2005. However, recently we have problems with checking in and get latest. Version of vault (client) is 4.0.4.

We use the 2003 compatible client add-in in Visual Studio for various reasons.

While the problem cannot be reproduced, we find it to occur often; usually about once a week. The problem is that once someone checks the code in, it won't get checked in on the server. And while the icon in VS2005 tells that the code has been checked in, the 'compare' feature tells there are differences between the code on the server and the local code. As a response to the problem, we try "Get Latest Version", which does nothing with the local code, keeping the version difference as it is.

A check out -> check in usually resolves the problem once it's found.

Please help; this is starting to get annoying. If you need any more information please let me know.

Cheers,
Stefan.

Post by **jclausius** » Wed Nov 21, 2007 7:39 am

If this happens again, quickly open up the Vault GUI client and check the pending change set. See if there are any files in there which you thought were checked in but did not succeed.

Also, see if there is anything relevant in the Vault Server Log which may help explain things.

atlaste · Post by **atlaste** » Wed Nov 21, 2007 12:10 pm

After browsing the server log for some time and making sense of it, I found these messages belonging to the original checkin. While I can't make the most of it, I noticed the 'a transaction is pending' message, so I thought it was worth to mention.

We always check errors using the normal vault client, since it's mentioned so many times in these forums. While I'm not 100% sure (but something like 90%) the client sees no diff when using the cached version but does spot a diff when comparing using the "repository version".

Does this help?

Due to these problems (and problems with CruiseControl.Net) I've decided to migrate to Vault 4.0.4, 2005 client, as described elsewhere on the forum. Perhaps that is a solution?

Cheers,
Stefan.

--- From the server log: ---

BeginTx beginning transaction
TreeManager: cache matches repository revision and folder security hasn't changed. Returning cached tree, revID 4986
(fc86c6e5-8ee7-4d95-9aa6-aa0e810964a1) BeginTx returned: Success
(fc86c6e5-8ee7-4d95-9aa6-aa0e810964a1) CheckIn: $/[somefile].cs returned: Success
(fc86c6e5-8ee7-4d95-9aa6-aa0e810964a1) CheckIn: $/[somefile].cs returned: Success
Receiving an uploaded file.
VaultFileUpload.aspx encountered: Success
Receiving an uploaded file.
VaultFileUpload.aspx encountered: Success
Ending transaction
Beginning SQL transaction 64634106
Attempting to acquire repository lock.
Acquired repository lock.
TreeManager Signal - Tx Begin - CacheLockId:5239925
TreeManager: A transaction is pending, but it belongs to the current user. Returning cached tree, revID 4986
EndTx(): Begin commit changes for TxID 5101, which will release repository lock.
SQL transaction 64634106 successfully committed.
Released repository lock for TxID 5101
EndTx(): End commit changes for TxID 5101
EndTx(): Begin cache tree changes for TxID 5101
EndTx(): End cache tree changes for TxID 5101
Beginning SQL transaction 41110714
SQL transaction 41110714 successfully committed.
TreeManager Signal - Tx End - TxID:5101 CacheLockId:5239925 RepID:6
Creating plugin thread...
(fc86c6e5-8ee7-4d95-9aa6-aa0e810964a1) EndTx (Revision - 5101) returned: Success
Getting repository Structure-> Rep ID: 6 Base: 4986 Target: -1
TreeManager: cache matches repository revision and folder security hasn't changed. Returning cached tree, revID 5101
VaultServiceAPI::GetRepositoryTreeDelta() UserID:2 RepID:6 Base:4986 Target:5101 Calling VaultRepUtil.DiffRepTrees() - in-memory tree diff.
GetRepositoryStructure returned: Success
Getting list of checkout changes.
Beginning SQL transaction 41552077
GetCheckoutListChanges: Transaction Started
TreeManager: cache matches repository revision and folder security hasn't changed. Returning cached tree, revID 5101
VaultServiceAPI::GetCheckoutListChanges() Status:0 UserID:2 RepID:6 FolderSecurity:False BaseList:3547 Target List:3548 RefreshFlag:True
SQL transaction 41552077 successfully committed.
GetCheckoutListChanges: Transaction Committed
GetCheckOutListChanges returned: Success

Post by **jclausius** » Wed Nov 21, 2007 1:07 pm

I didn't see anything like EndTx() succeeded in the server log. Was there something there? It would let us know the transaction succeeded.

Is it possible you have re-mapped working folder assignments used by Visual Studio when the project was first bound? You should let Visual Studio decide where to place working folders (because it will constantly be changing any assignments you've re-mapped within the Vault GUI client). When the two get out of synch weird things can happen like the scenario you described.

What I'm trying to figure out is if the file was checked out to a different folder than where you are making changes to the file. In a case like this, the Vault client would do an "Undo" of the checkout or check in a file with no change because the changes are actually in a different folder.

atlaste · Post by **atlaste** » Wed Nov 21, 2007 3:01 pm

> I didn't see anything like EndTx() succeeded in the server log. Was there something there? It would let us know the transaction succeeded.

No, this is everything there is...

> Is it possible you have re-mapped working folder assignments used by Visual Studio when the project was first bound? You should let Visual Studio decide where to place working folders (because it will constantly be changing any assignments you've re-mapped within the Vault GUI client). When the two get out of synch weird things can happen like the scenario you described.

We did an "open from source control". Nothing fancy there.

> What I'm trying to figure out is if the file was checked out to a different folder than where you are making changes to the file. In a case like this, the Vault client would do an "Undo" of the checkout or check in a file with no change because the changes are actually in a different folder.

Yes. And no. I did test CruiseControl.Net on my machine. Which indeed re-mapped vault client to another folder. When I noticed that I closed visual studio and reset the binding on the vault client, started the visual studio again and did a get latest.

But that was days before this occurred...

Is it possible this is the case, and if so, how can I resolve it?

Thanks,
Stefan.

Post by **jclausius** » Wed Nov 21, 2007 3:09 pm

It's hard telling if this occurred. The best thing to do is wait until you see this again. When you do, see if you can check things out with the GUI client to see if the file is still checked out or if the working folders have been re-mapped.

Temporarily placing the server in debug logging mode also would also help capture additional information at the time this occurs.