Vault Client-Side Cache Files

A collection of information about Vault, including solutions to common problems.

Moderator: SourceGear

Post Reply
sterwill
Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Vault Client-Side Cache Files

Post by sterwill » Mon Dec 15, 2003 2:52 pm

The Vault and Fortress clients (Windows Forms, Visual Studio IDE, and command-line) store some data on the local filesystem to speed up operations and to allow clients to compute deltas to reduce network traffic. This knowledge base article describes the cache files the client uses and how to safely remove them to reset a Vault or Fortress user's client-side settings.

Update: In Vault 8.0.1 and higher, you can delete parts of the cache through Tools - Options - Local Files - Cache Location. Click the Reset Repository Cache to be shown the options of what you can reset.

Local cache files are stored in a path like the following:

Vault versions 3.07 and earlier:
%APPDATA%\SourceGear\Vault_1\Client\{repository-guid}\{vaultuser}\

Vault versions 3.1 and later:
%USERPROFILE%\Local Settings\Application Data\SourceGear\Vault_1\Client\{repository-guid}\{vaultuser}\

Fortress 1.0 and VaultPro 5.1.2 and later:
%USERPROFILE%\Local Settings\Application Data\SourceGear\Fortress_1\Client\{repository-guid}\{fortressuser}\

On Vista and Windows 7 and later Windows versions that path is:
%USERPROFILE%\\AppData\Local\Sourcegear\Vault_1\Client\{repository-guid}\{vaultuser}\

On Mac OS the cache location should be located at :
~/Library/SourceGear/Vault(Pro)_1/com.sourcegear.vault.guiclient/...

The following information applies to Fortress and VaultPro as well as Vault:

{repository-guid} is a GUID text string that uniquely identifies a Vault repository. This GUID is initialized when the repository is created on the Vault Server and never changes. {vaultuser} is just the string name of the Vault user who needs to store cache files.

Strictly speaking, all the files are not cache files (copies of data Vault could request again if it needed to). Some of the files hold information about changes to the repository that have not been committed yet. Here's what all the files contain:

CacheMember_CheckOutList - New for Vault 3.0 - Contains a cached copy of the list of checked out files (and the users who have them checked out). Deleting this file will cause Vault to request the entire list the next time it is started.

CacheMember_ChangeSetComment - This file simply contains the comment for the change set that has not been committed yet. Deleting this file will cause Vault to lose its change set comment.

CacheMember_ChangeSetItems - These are the items in the Pending Change Set that are not modifications to existing files in working folders (those changes are re-discovered whenever Vault examines a working folder). Kinds of pending changes that would be in this file are things like Branch, Share, Delete, Add File, Create Folder, and Rename operations. Deleting this file will cause Vault to forget about all change items stored in this file.

CacheMember_ExpandedNodes - This file contains the tree nodes that were expanded in the main tree control when Vault was last closed. Deleting this file will cause Vault to expand only the root node the next time it opens the same repository.

CacheMember_KnownChanges - This file contains changes discovered in working folders (things that would show up in the Pending Change Set as Modified). This file may not exist on your system depending on your VSS/CVS-style settings. Since Vault will always re-scan for these changes on connect to a repository, you can delete this file (Vault will just have no items in its Pending Change Set until the scan completes).

CacheMember_LastStructureGetTime - Stores the last time Vault requested a repository structure delta from the server. If you delete this file, also delete CacheMember_Repository.

CacheMember_Repository - Stores the entire repository structure retrieved from the server. Deleting this file will cause Vault to request a large delta containing all files and folders the next time it connects to a repository. If you delete this file, also delete CacheMember_LastStructureGetTime.

CacheMember_PendingLocalDeletions - Vault keeps track of things that were deleted from the repository by you and other users, but have not been deleted from your working folders. These files and folders are stored here, and the next time you perform a "Get Latest Version" on a folder, this list of deletions is checked for any that fall underneath the selected folder. They are then deleted from your working folder or not (according to your user options). Deleting this file will cause Vault to never try to delete these items from your working folders.

CacheMember_SelectionString - Just contains the selected node in the tree view. Deleting this file will cause Vault to select the root node in the tree view the next time the same repository is opened.

CacheMember_WorkingFolderAssignments - Contains the assignments between repository paths and local disk paths. Deleting this file will cause Vault to forget all working folder associations.

All of the cache member files can be deleted individually, except for CacheMember_Repository and CacheMember_LastStructureGetTime, which should always be deleted together. Vault will re-create any missing files the next time it is run.

Always make sure no copies of Vault are running if you delete these files. Vault does system-wide locking of these files while it is running, and deleting them without performing the correct locking may cause bad things to happen.

Update: In Vault 8.0.1 and higher, you can delete parts of the cache through Tools - Options - Local Files - Cache Location. Click the Reset Repository Cache to be shown the options of what you can reset.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`

Post Reply