SourceGear Vault Source Control Block¶
SourceGear Vault Source Control Block.
Version¶
Available from version 1.0
Examples¶
Minimal example
1<sourcecontrol type="vault" />Full example
1<sourcecontrol type="vault" autoGetSource="true" applyLabel="true">
2 <executable>c:\program files\sourcegear\vault client\vault.exe</executable>
3 <username>my_username</username>
4 <password>my_password</password>
5 <host>my_buildserver</host>
6 <repository>my_repository</repository>
7 <folder>$</folder>
8 <ssl>true</ssl>
9 <timeout units="minutes">10</timeout>
10 <useWorkingDirectory>true</useWorkingDirectory>
11 <workingDirectory>project/src</workingDirectory>
12</sourcecontrol>Configuration Elements¶
| Element | Description | Type | Required | Default | Version |
| type | The type of source control block. | String - must be vault | Yes | n/a | 1.0 |
| applyLabel | Specifies if CCNet should apply the build label to the repository. | Boolean | No | false | 1.0 |
| autoGetSource | Specifies if CCNet should automatically retrieve the latest version of the source from the repository. | Boolean | No | true | 1.0 |
| cleanCopy | If true, the source path will be emptied before retrieving new source. | Boolean | No | false | 1.0 |
| dynamicValues | The dynamic values to use for the source control block. | Dynamic Values array | No | None | 1.5 |
| executable | The location of the Vault command-line executable. | String | No | C:\Program Files\SourceGear\Vault Client\vault.exe | 1.0 |
| folder | The root folder to be monitored by CCNet. | String | No | $ | 1.0 |
| historyArgs | Extra arguments to be included in the history commandline. | String | No | -excludeactions label,obliterate -rowlimit 0 | 1.0 |
| host | The name of the Vault server. | String | No | None | 1.0 |
| otherVaultArguments | Any other aruuments to pass into the executable. | String | No | None | 1.0 |
| password | Password for the Vault user. | PrivateString | No | None | 1.0 |
| pollRetryAttempts | The number of automatic retries when failing to check for modifications before an exception is thrown. | Int32 | No | 5 | 1.0 |
| pollRetryWait | The number of seconds to wait between retries when a check for modifications fails. | Int32 | No | 5 | 1.0 |
| proxyDomain | The Windows domain of the HTTP proxy Vault should use. | String | No | None | 1.0 |
| proxyPassword | The password for the HTTP proxy Vault should use. | String | No | None | 1.0 |
| proxyPort | The port on the HTTP proxy Vault should use. | String | No | None | 1.0 |
| proxyServer | The host name of the HTTP proxy Vault should use. | String | No | None | 1.0 |
| proxyUser | The user name for the HTTP proxy Vault should use. | String | No | None | 1.0 |
| repository | The name of the Vault repository to monitor. . | String | No | None | 1.0 |
| setFileTime | The modification date that retrieved source files will have. Must be one of: \* checkin - the date/time the file was checked in \* current - the date/time the file was retrieved from Vault \* modification - the date/time the file was last modified |
String | No | checkin | 1.0 |
| ssl | Should SSL be used to communicate with the Vault server. | Boolean | No | false | 1.0 |
| timeout | Sets the timeout period for the source control operation. | Timeout Configuration | No | 10 minutes | 1.0 |
| username | Vault user id that CCNet should use to authenticate. | String | No | None | 1.0 |
| useWorkingDirectory | CC.NET 1.0: Determines the working directory into which Vault files will be retrieved. Supply true if you want CCNet to use the Vault folder working directory created for the build user using the Vault GUI (recommended). Supply false if CCNet should use the CCNet working directory. CC.NET 1.1: Determines if the source will be retrieved into a Vault Working Folder. | Boolean | No | true | 1.0 |
| workingDirectory | The root folder where the latest source will retrieved from Vault. This path can either be absolute or it can be relative to the CCNet project working directory. CC.NET 1.1: If this element is missing or empty, Vault will attempt to use the directory set as the user's working folder. Note that this is simply the destination path on disk. Whether or not this location is a Vault Working Folder is determined by the useWorkingFolder element. To use the same path as the project, it is necessary to use "." (without the quotes) rather than leaving this empty, as you could in CC.NET 1.0. |
String | No | Project Working Directory | 1.0 |
Notes¶
Plugin available for Vault 4.1\+ (or Fortress 1.1\+)¶
SourceGear has released a plugin that offers better performance and accuracy by interacting directly with Vault via its API, rather than the command line. The configuration format is almost identical to this one, making migration easy. The plugin and its documentation can be downloaded from SourceGear's site (http://www.sourcegear.com/downloads.html).
Vault Working Folder Defined¶
Most version control systems have distinct commands for "get me the source" and "get me the source into a folder where I may make changes." Vault is no exception. A working folder is a folder where Vault will keep track of your changes. If you're using CC.NET 1.1.0.2172\+, the useWorkingFolder setting determines whether Vault retrieves source into a working folder. For build purposes, there are typically two situations where you want to retrieve source into a working folder:
1. Your build script changes source and checks in the change
2. It's taking longer than you'd like to retrieve the source
Because of the additional state information kept by Vault for working folders, retrieving source into a working folder is usually faster than into a non-working folder. The trade-off is that more disk space will be used for cache and state data.
Filtering out Label Changes¶
If you are using Vault 3.x or later, labels will automatically be filtered. However, if you are using an earlier version of Vault and you apply a label as part of your build process, this will kick off another build. you will need to use a Filtered Source Control Block to get around this. If your build server uses a specific user id to integrate with Vault, you can set up a UserFilter to filter out all changes made by that user.
Problems with CCService and Vault 3.0.2\+¶
If you are experiencing problems detecting modifications using CCService after upgrading to Vault 3.0.2, it may be related to the enhanced security features of the Vault server. You should try the following process to fix this issue:
1. reinstall the Vault Server to have the IIS Process Model run as System (ie. not Machine)
2. change the CCService to run as an actual user, not as LocalSystem.
Problems with releases prior to Vault 3.0¶
For versions of Vault prior to 3.0, the -excludeactions argument is not supported. To get around this problem you should explicitly specify the <historyArgs> element in your ccnet.config file so that it does not contain that argument (ie. set it to <historyArgs>-rowlimit 0</historyArgs>.
NAnt Vault Tasks¶
SourceGear has produced some NAnt tasks for Vault that can be downloaded from http://www.sourcegear.com/vault/downloads.html.
Turning off the creation of _sgbak folders¶
Using CC.NET 1.1.0.2172\+ and Vault 3.1.7\+, _sgbak folders are never created.
Using older versions, the use of the _sgbak folder can be turned off using the GUI client. This is a user and machine-specific setting, so you need to launch the GUI client on the CCNet machine and log in as the same Vault user that CCNet is using (as specified it ccnet.config).
Tools\|Options -> Local Files -> Cache/Backup Locations -> Un-check "Save files in backup folder before overwriting"
Contributions¶
Code contributed by Ryan Duffield, Leo von Wyss and Ian Olsen.
Automatically Generated¶
Documentation generated on Monday, 26 May 2014 at 7:18:03 AM