Folder Problems -- State information incompatible with Vault

Addie Gisser · Post by **Addie Gisser** » Thu Feb 17, 2005 3:21 pm

I am using Vault 3.0.2. I created a shared folder with many inherited shared sub folders. Whenever I try to access one of the subfolders under the shared folder I get the following message:

"The working folder state information for C:\Dev\5000\Main\GC\GCGraphics is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Could not detect the file type in the supplied stream."

If I choose a different working folder, all is well. However, this is the working folder that needs to be selected since it is a shared subfolder. Deleting the actual physical folder on my PC has no effect on this problem.

I have tried to branch the shared folder so I could delete the offending subfolder but the branch fails with the following message (Main is the shared folder that I am attempting to branch):

[2/17/2005 3:11:35 PM] Getting latest version of $/5000/Main/GC
[2/17/2005 3:13:40 PM] Preparing data to begin transaction
[2/17/2005 3:13:40 PM] Beginning transaction
[2/17/2005 3:13:40 PM] Branch $/4000/Main
[2/17/2005 3:13:40 PM] Ending the transaction
[2/17/2005 3:14:22 PM] Server unavailable for transaction end
[2/17/2005 3:14:22 PM] An exception was encountered during the transaction. Exception: Exception of type System.Exception was thrown. at VaultClientOperationsLib.ClientInstance.Commit(ChangeSetItemColl givenItems, Boolean keepCheckedOut, Boolean removeLocalCopy, Boolean bIsImport, DateTime dateImport, Int32 nUserIDImport, Int64& nRevID)
[2/17/2005 3:14:22 PM] Transaction failed
[2/17/2005 3:14:22 PM] Item $/4000/Main caused the transaction to fail: The branch could not be completed because the object or one of its children is checked out.
[2/17/2005 3:14:22 PM] Transaction failed

Some additonal information:

The subfolder from which the problem subfolder is shared does not exhibit this problem.

If I delete the problem shared folder (GCGraphics in the above message), then the corresponding folder from which it was shared is also deleted (I guess this is as designed). Recreating the same folder in the Main that I am sharing recreates the problem.

What do I do to resolve this?

Thanks,

Addie

lbauer · Post by **lbauer** » Mon Feb 21, 2005 3:40 pm

It sounds like your view of the tree may not reflect the true state of the tree.

I'd suggest deleting your client-side cache files in your %appdata%\Sourcegear\Vault_1\Client directory. You'll need to reset your working folders and if your _sgvault directory is kept there, you'll need to do a fresh get as your file status will be unknown.

Here's the suggested sequence: Close any Vault clients you have open (GUI and IDE). Delete the cache files. Restart IIS.

Here's additional info on client-side cache files:

http://support.sourcegear.com/viewtopic.php?t=6

mlippert · Post by **mlippert** » Fri Apr 15, 2005 12:53 pm

This just happened to me.
I'm using the 3.0.6 client and our server is 3.0.5.

From the Vault client I did the following:
I had just set a new working folder earlier today and done a get latest.

I had edited a file, and then someone else had also edited it and checked it in.

I did another get latest, and the file changed to needs merge.

I did an undo checkout from the pending changeset.

The IDE gave me some wierd message source control message, and I told it to do nothing and then I closed it.

I then went back to the Vault GUI and tried to do another Get Latest and I got the error mentioned in this thread:

The working folder state information for E:\Projects\Designate15M1\ECMF is incompatible with this version of Vault. Please choose a different working folder path. The specific compatibility exception was: Could not detect the file type in the supplied stream.

I shut down the Vault GUI, but I started getting the message over again as soon as I logged back in. I'm going to try deleting my client-side cache files as described by Linda. I'm not sure if she meant restart IIS on the server (the only IIS I think Vault is using) and if so, why?

Mike

dan · Post by **dan** » Fri Apr 15, 2005 1:04 pm

It is definitely the client cache that needs reset, not the server (or IIS).

If you can get to the point where you can reproduce this, we would very much like to figure out what happened.

mlippert · Post by **mlippert** » Fri Apr 15, 2005 1:13 pm

Well I deleted most of the client cache files except the CacheMember_WorkingFolderAssignments file, and then restarted the Client and got the same persistent dialog message.

I got the message to go away by renaming the working folder on my hard drive (so the working folder being pointed to didn't exist).

I then did a set working folder on the main folder in Vault specifying Remove working folder association AND force all subfolders to use inherited working folder.

And the client seems to indicate that succeeded (at least the working folder status is empty both on the main folder and the ECMF folder mentioned in the dialog message).

However, if I now go rename the old working folder back to it's original name I start getting these messages again.

Given this state of affairs, is there some test or some logging that you'd like me to turn on to see what's happening?

Mike

dan · Post by **dan** » Fri Apr 15, 2005 1:17 pm

Do you store your working folder state in the working folders (as opposed to the Docs & Settings folder)?

If so, this makes sense if a state file got corrupted within your working folder. Even if you delete the Docs & Settings cache, it is still trying to read the file within the working folder that you set.

mlippert · Post by **mlippert** » Fri Apr 15, 2005 1:18 pm

Even after I remove the working folder association?
(but yes I do store the working folder state in the working folders _sgvault subdirectories).

dan · Post by **dan** » Fri Apr 15, 2005 1:32 pm

If the problem re-appears after restoring the working folder, then there must be a working folder association that still points to that working folder (is there an issue with unsetting all working folders maybe?).

You might verify that no other working folder associations exist for this repository pointing to the existing working folder that seems to have the problem.

mlippert · Post by **mlippert** » Fri Apr 15, 2005 1:50 pm

Thanks, that was it.

The working folder that was causing the problem was from a branch. That is the working folder association I removed, that wasn't helping.

I went looking through the other folders and lo and behold the trunk working folder was pointing to that branch's working folder!
I'm assuming that somehow Visual Studio must have reset the trunk's working folder to that of the branch (when VS gave me that message I had a solution in the branch open).

I reset the trunk's working folder back to the correct location, and then reset the branch's working folder back to its correct location (which is the location that was giving me the error), and now I only get 1 error dialog when I do a get latest on the branch.

So I deleted the offending ECMF folder (along with all of its subfolders including _sgvault) and did another Get Latest from the root of the branch and it worked fine.

Mike