Shared files not updating and causing checkin error

malcolmstorm · Post by **malcolmstorm** » Wed Apr 25, 2007 10:07 am

We use shared folders (projects) a good deal across our solutions in C#. Today I have experienced a nasty problem when trying to commit changes to a shared file (a simple build script) that is shared accross about 10 solutions. We are using an edit-merge-commit senario as well.

The error I get is:

An exception was encountered during the transaction. Exception: Server was unable to process request. --> Error in the application. at System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
at VaultClientNetLib.ClientService.VaultService.BeginTx(Int32 nRepID, String strComment, VaultRequestItem[]& requests, String& strTxID)
at VaultClientNetLib.VaultConnection.BeginTx(Int32 nRepID, VaultRequestItem[]& requests, String& strTxID, String comment)
at VaultClientOperationsLib.ClientInstance.Commit(ChangeSetItemColl givenItems, String strChangeSetComment, Boolean keepCheckedOut, Boolean removeLocalCopy, CommitType committype, VaultDateTime dateImport, Int32 nUserIDImport, Int64& nRevID, Int32[]& retBegEndTx)

This error occurs on other users machines on the same files so this does not appear to be a problem with the client cache. On closer inspection, the versions of the shared files in the offending folder are not the latest versions in the original directory. The properties of the files confirm that they are shared.

I deleted the entire folder and rebuilt it which seemed to get around the problem but the same thing has happened in another part of the tree now!

We are using 3.5.1. Would an update to 3.5.2 fix this?

Beth · Post by **Beth** » Wed Apr 25, 2007 12:26 pm

Was this a VSS database previously? If so, were those shares that were imported from VSS or were all of them Vault shares?

malcolmstorm · Post by **malcolmstorm** » Thu Apr 26, 2007 5:30 am

No the offending shares are inside a repository that was created from scratch. The shares were created in the Vault Client.

Beth · Post by **Beth** » Thu Apr 26, 2007 8:13 am

Do the shared files still have the shared icon versus a regular folder? If you look through history, had any branches occurred on those folders after the share was done?

Is this with Visual Studio integration? There could be something going on with the binding there. If using the integration, try a few tests with the Vault GUI and see if the same thing happens.

malcolmstorm · Post by **malcolmstorm** » Thu Apr 26, 2007 8:27 am

The offending folder still displays the shared icon. It has subfolders with some files moved between subfolders in the past (it is the sandcastle files shared to all projects.) But no actual branches have been undertaken. The problem is that same error was occuring on a much simpler set of shared files too.

I would be happy to simply delete the sandcastle folder (we are no longer sharing it into individual project trees due to its size) but the vault client keeps coming up with the strange SOAP error on all client machines tried. I am very concerned that the database is now unstable.

We are not using the VS integration. We use the client for everything under the edit-merge-commit model.

Beth · Post by **Beth** » Thu Apr 26, 2007 1:22 pm

Can you send an email to support at sourcegear.com (attn: Beth) with a link to this forum post?