A list of individual repositories is supplied under the Source Control Repositories heading. The list is sorted alphabetically in ascending order. To view the configuration of a repository, click the repository name under Source Control Repositories heading.
The Repository Settings page shows the properties associated with this repository:
The repository name can be modified from this page. Modify the repository name, then click Save. Note: Vault Clients will continue to show the old repository name until the client-side cache is deleted and rebuilt.
When checked, two people cannot have the same file checked out at the same time. This will apply to the entire repository.
The default is Unchecked.
When checked, all check ins to the repository must have a check-in comment.
The default is Unchecked.
When checked, Enable Folder Security allows you to set access rights by folder for groups and users.
If a folder’s security is turned off, rights assignments are not deleted. So if a repository’s security is turned off, then on again, it will have the same security rights it had before it was turned off.
The default is unchecked for increased performance of Vault operations.
When checked Enable Keyword Expansion keywords located in files of the specified types will expand when committed to the Vault Professional repository.
The default is Checked.
Default access can be assigned to all users in a new repository by selecting either "Access" or "No Access" in the Default User Access dropdown.
The default is Access.
When checked, all check ins to the repository must have be associated with a bug or work item.
The default is Unchecked. Note: this option is available if you are using FogBugz with Vault Standard, or Vault Professional with Work Item Tracking.
This section allows you to configure Mergeable files, File Exclusions, Folder Exclusions and EOL Conversion.
The Groups page lists the groups associated with that specific repository. New groups can be added from this page, and existing group properties can be modified.
The Groups Table is a table listing the groups associated with the individual repository. The columns can be sorted on this table by clicking on the appropriate heading. Clicking a second time will reverse the sort. The default sort is alphabetically on the Group column.
Group – The group’s name.
Owner – The owner of the group, which can be global or repository-specific.
Description – A brief description of the group.
Access Rights – Click View to see the Group's access rights to this and other repositories.
Modify – Click the pencil icon to modify the selected group.
Delete – Click the red "X" icon to delete the selected group.
Click Add to create a new group. Please see Reference -> Add/Edit Group for additional details. Unlike groups created under Server Settings -> Groups, these groups will be owned by the individual repository.
To edit an existing group, click the pencil icon in the Modify column. From the Modify page, the name, description and user members of a group can be modified. Please see Reference -> Add/Edit Group.
The Repository Access page for an individual repository summarizes the groups/users that can access that repository. Please see Security -> Repository Access.
The Repository Access page for an individual repository describes rights to the repository for groups and users. Clicking on the Edit icon will result in a drop-down menu from which these rights can be changed. Click the disk icon to save any changes or the "X" to cancel your changes.
The Groups table contains the name of each group, their assigned rights, and the option to edit or delete these rights. As new groups are assigned to a repository, their rights (access/no access) can be set from this page.
The Users table contains the name of each user (or only active users if the Hide Inactive Users checkbox is checked). The user’s rights are listed and can be edited by clicking the edit icon. The repository group from which the user obtained these rights is given in the Inherited From column. The columns can be sorted on this table by clicking on the appropriate heading. Clicking a second time on the heading will reverse the sort. The default sort is alphabetically on the User column.
The Hide Inactive Users checkbox determines whether the User Access list contains all users or only active users.
The Folder Security page allows you to view and edit the folder security settings for any folder in this repository. Please see Overview -> Security -> Folder Security Rights for more information.
Rights can only be assigned by folder if Folder Security is enabled for the repository.
The Folder Tree of the selected repository is displayed. When a folder is selected in the tree, the Rights Table displays the rights of the selected folder.
The Rights Table is a table of all users and all groups, and displays the actual rights for the selected folder for each user and group. The rights for a user or group are determined based on actual rights assignments, inherited rights from a higher level, or default rights. See Folder Security Rights for the rules applied when determining rights at a specific folder.
The Rights Table has the following columns:
The name of the user/group whose rights are shown in this row.
The rights of the user or group for the selected folder in the Folder Tree.
Clicking the pencil icon will cause a drop-down menu to appear in the rights column. The appropriate level can be selected, and then saved by clicking update.
This column describes how the user obtained the rights listed in the Inherited From column. There are four ways that a user can obtain rights to a folder:
The user has no assignment to the folder or any of its parents. The user’s default Folder Security rights will be used.
The user has a direct assignment to this folder. Directly assigning rights to a user will automatically create a link that enables the Administrator to delete the assignment.
The user has a direct assignment to a parent of this folder. The repository path by which the user obtained these rights is given in the Inherited From column.
The user belongs to a group which has a direct assignment to the folder or a parent of the folder.
If making changes to a group’s folder rights, it is recommended that the group folder rights changes are applied before making folder rights changes for individual users. Users can inherit their rights from a group and changing a group’s rights may affect user rights.
The Edit Rights column allows you to modify the rights of a specific user or group. The values match the selected user or group. Clicking the icon in the edit column will cause a drop-down menu to appear in the neighboring rights column. Click the green disk icon to add the assigned rights to the selected folder. Click the "X." to cancel.
The Undo Check Out page allows you to undo any current checkouts in any repository.
The Files currently checked out list contains the files currently checked out in the selected repository, sorted by file name.
The list can be sorted by clicking the column heading. Click the heading again on the sorted column to reverse the sort. The default sort is alphabetically on the User column.
Folder Path – The full path of the parent folder of the file.
File – The names of the checked out file
User – The names of all users who have the file checked out.
When – The time the file was checked out.
This list is refreshed every time the page is reloaded.
To undo checkouts, click the check boxes next to the check outs you wish to undo, then click Undo Check Out. To select all check outs, click the check box to the right of Folder Path column heading. Uncheck the box to undo the check outs for all selected files.
The Rebind page will search through a repository folder, searching for Visual Studio solution and project files. These files will be edited to bind them to the Vault Standard Visual Studio Enhanced Client. Only Visual Studio 2005, 2008, 2010 or 2012 files can be rebound with this page. The following file types are supported:
The rebinding of other project types is not supported. Unsupported project types should be bound manually.
The Rebind Projects function walks through the following steps:
In this step, select the repository node that will be searched.
In this step, enter the server's URL. This URL must be reachable from all your user's computers.
This step lists the project and solution files that were found. If there were errors with binding any of the found files, it will be noted in the "Errors" column. If there are any errors, that file will not be edited and checked in the next step. Clicking the Rebind button will commit the files.
Web site projects will only be rebound if the following two conditions are met:
The solution that contains the web site project is being rebound.
The relative path between the solution and the web site folder is the same in both the Repository and in the solution file.
For more help on this, see:
The Obliterate page is used for obliterating deleted files and folders from the repository.
This permanently erases the contents and history of the file or folder but keeps some meta-information so history entries can show that obliterates happened from their parent folder. Obliterating an item causes the parent folder version to be incremented.
Any item that has been branched cannot be obliterated until its branches are obliterated. A branch maintains links in the database to the trunk for versions prior to the branch point. Therefore, obliterating a trunk would obliterate early versions of the branch, so Vault Standard prevents this from happening. Note that snapshots are considered branches in this context, and all branches ever created from a trunk must be obliterated before obliterating the trunk.
Obliterating files and folders is not recommended because they cannot be recovered. This will create gaps in the history. An obliterate can cause Folder ExportImport and Folder Rollback to fail, since these operations must recreate history. Obliterate should only be used if you are absolutely sure you will never need these files again.
The Folder Tree of the selected repository is displayed. When a folder is selected in the tree, the Deleted Items table is updated to reflect the items that have been deleted in the selected folder.
All files and folders that have been deleted from the repository, but not obliterated, are listed. Select any number of files and folders to be obliterated.
To select all items in the list, click the checkbox to the right of the "Item" heading. Clear the check box to deselect all items in the Item column. You will be asked to confirm the obliteration action.
Click the Obliterate button to permanently remove the selected items from the repository.
Check the Enable Keyword Expansion to expand keywords located in files of the specified types when committed to the Vault Standard repository.
Find in Files provides the ability to search for a word or string in text-based (non-binary) files in a Vault Standard repository.
Vault Standard users can access the Find in Files command from the Tools menu of the Vault Standard GUI Client. The search results are displayed in the Find in Files tab at the bottom of the Vault Standard Client.
Find in Files is also available in the Vault Standard Command Line Client
By default, Find in files indexing is Off. Find in Files must be enabled for each repository you wish to index.
A Vault Index Service is installed with the Vault Standard server.
File data is indexed and stored in the sgvaultindex database.
Text-based (non-binary)files are stored on the Vault Standard server machine in searchable cache. The default location for the cache is C:\Windows\temp\sgvaultindex\cache. This cache can also be configured to be stored on a different machine by modifying the VaultIndexService web.config file. The cache is updated with each checkin that modifies file contents.
Vaultindexservice.txt is the log file for the Vault Index Service. If you encounter problems with the Index Service, consult this log file. The default location for this file is C:\Windows\Temp\SGVaultIndex
Select the On radio button to enable the Index Service. Click the Save button to save your setting. Indexing may take a few moments to complete, and increased CPU activity may be seen while indexing takes place.
The Suspend radio button stops further indexing. Suspend maintains the data in the current cache but does not update the cache. New additions or modifications to files in the repository will not be indexed for Find in Files while indexing is suspended.
The Off radio button turns indexing Off. Click the checkbox if you wish to purge Find in Files index data. Purging index data removes the cached data on the server machine. After the request to change the settings have been sent to the Index Server it may take a moment before the change takes effect.
NOTE: If you purge the Find in Files index data and subsequently re-enable Find in Files, re-indexing the repository may take longer to complete than if you suspend Find in Files indexing.
When a repository index is first built, statistics used by SQL Server may not
be available due to the large size of insertions made to the sgvaultindex
database. In order to optimize the database for use, you will need to manually
update the statistics within the 'sgvaultindex' database for that given
repository. Note, as of Vault 6, this is a manual process as you can schedule
maintenance routines to fit into your own schedule in order leave you in control
of your SQL Server resources.
See this KB article for details.
The Shadow Folders page allows you to determine which folders in your repository will be shadowed.
A shadow folder is a local folder that contains the contents of a repository folder, and is kept up-to-date in the shadow folder by the Vault Standard server as changes are applied to repository folder.
A special Shadow Folder Web Service is installed with the Vault Standard server that is notified of changes as they happen, and the Shadow Folder Service keeps the local disk up to date. A shadow folder must be accessible from the machine the Shadow Folder Web Service is located on.
The Shadow Folder Web Service is configured to run under the Vault Standard Admin user account. If you change the Admin user’s password, you must do it from the Vault Standard Admin Web Client, and not from another Vault Standard client. Otherwise, the Shadow Folder configuration data will not get updated to reflect the password change, and Shadow Folders will not be updated until the password is corrected.
Note on UNC paths: If you want to shadow files to a UNC path (e.g., one that you
specify as \\machinename\folder, rather than one that is local to the
Vault Standard server), there are also additional configuration steps
required. See a Knowledge Base article at
Folders with UNC Paths for more information.
The Shadow Folders Table contains all the associations between repository folders and the shadow folder targets. The table provides the following information for each configured shadow folder:
The Repository Path of the directory being shadowed.
The path to the directory on disk where the Shadow Folder Web Service will place repository files and keep them up to date.
This value indicates if the read-write flag has been set to Read-Only for any files that are placed in the shadow folder. If the value is False, files will be writable in the shadow folder; if the value is True, files will be read-only.
The timestamp on files when they are fetched to the Shadow Folder.
Click on the Edit icon to modify the selected shadow folder association.
Click the red "X" icon to delete the Shadow Folder association. The shadow folder and files must be manually removed from disk.
Click the red "X" in the the Delete column to delete the selected shadow folder association from the Shadow Folders list. Note that this does not delete the files from the disk, but merely deletes the association.
To create a Shadow Folder, enter information in the New Shadow Folder section of the Shadow Folders page.
Enter the Repository Path of the directory being shadowed. Example: $/MyFolder.
Enter the path to the directory on disk where the Shadow Folder Web Service will place repository files and keep them up to date. Examples: C:\Myfolder. Verify that the account used by the Shadow Folder Service has read/write permissions on the Shadow Directory.
Files in the shadow folder can be read-only or writable. The default is "Don't set read-only flag for all files," which will make files in the shadow folder writable. Select If you want files in the shadow folder to be read-only, choose "Set read-only flag for all files" from the dropdown.
Use the dropdown to choose to optimize shadow folder for speed, or to synchronize the shadow folder with the repository. The default is Optimize for Speed.
Optimized for Speed - After the Shadow Folder target has been retrieved to the file system, only changes due to repository transactions are reflected on disk. The Shadow Folder target will not be fully synchronized with the Shadow Folder's repository folder if changes are directly made to items on the file system. Only the change set items committed to the repository will be synchronized in the Shadow Folder target. This is the default setting for new shadow folders. Any items manually deleted from the Shadow Folder will be not be re-fetched until those items are updated in the repository. Note, however, any items manually added to the Shadow Folder not be deleted by the Shadow Folder Service.
|You edit File A in the Repository and File B on disk in the Shadow Folder. When File A is checked in, only the Shadow Folder copy of File A is updated to match the repository version. File B will not be updated by the the Shadow Folder Service until File B has been updated in the repository.|
|You delete File C in the Shadow Folder. File C will not be re-fetched to the Shadow Folder unless File C is updated in the repository.|
Synchronized with Repository - The contents of the files in the Shadow Folder match the contents of the files in the the repository folder. If changes are made directly to any of the files on disk within the Shadow Folder, these changes will be overwritten on the next Shadow Folder update.
Any files added to the repository or deleted from the repository will be added to or deleted from the Shadow folder directory. Also, any items manually deleted from the Shadow Folder will be re-fetched. Note, however, that any manually added items will not be deleted from the Shadow Folder directory.
|You edit File A in the Repository and File B on disk in the Shadow Folder. When File A is checked in, both File A and B in the Shadow folder will be updated to match the repository version.|
|You delete File C in the Shadow Folder. On the next repository transaction that is shadowed, File C will be re-fetched to the Shadow Folder.|
This option allows you to establish a default for the timestamp of the files retrieved to the shadow folder.
The timestamp will be the time the file was downloaded from the server to the shadow folder. This is the default setting.
The timestamp will be the time the file was last modified on a client machine.
The timestamp will be the server time at the time this version of the file was checked in.
Click Add to add the repository/shadow folder association to the database, and to begin shadowing the folder.
For detailed information on troubleshooting Shadow Folder plugin errors,
this KB article.
The Statistics page gives an overview of repository data.
|Revisions||The number of revisions in this repository's complete history. In other words, a count of the number of commits (whether automatic or manual) which have occurred.|
|Folders||The number of top- and sub-level folders in the reposity tree. Also shows the number of deleted folders.|
|Files||The number of files in the repository tree.|
|Tree Size||The combined size of all files in the repository (based on the latest revision).|
|Disk Space Needed||An estimate of the disk space needed to store a copy of the entire latest revision of the repository's files.|
|Database Size||The size of the repository's database structure, including all history, previous revisions, shares, etc.|