Configuring VCS Roots
A VCS root is a cornerstone of the TeamCity ←→ VCS repository communication. This integral element defines a connection to a VCS provider required to perform a wide range of operations: repository checkout, code sources tagging, communicating build statuses back to VCS, and so on.
VCS roots store the following information:
Fetch and push URLs that TeamCity uses to pull and push remote files.
Branch information: the list of repository branches TeamCity should track and which branch is the default (main) one.
Authentication settings: credentials TeamCity uses to access a repo.
Checkout settings: specify how remote files should be stored and whether submodules should be checked out along with the main repository.
Custom changes polling settings that allow you to override the default 60-second interval.
Sections related to VCS roots are available in both project and configuration settings.
However, configurations never own roots. You can "attach" a VCS root to a configuration, but roots are always stored in (owned by) projects. This technique results in the following:
A VCS root can be attached to multiple configurations, meaning that multiple build configurations can access the same repository with the same auth and checkout settings.
A single configuration may have multiple VCS roots attached, which allows you to work with different repositories within one configuration.
Editing VCS roots affects all configurations that use it. When modifying VCS root settings, you have an option to duplicate this root and store updated settings in this new clone, keeping the original root unchanged. This allows you to customize one build configuration but leave other configurations that share this root unaffected.
Although a VCS root is an existential part of any build configuration that works with a remote repository, in many scenarios TeamCity generates roots automatically and does not require that you create them by hand for each new build configuration. See this tutorial for an example.
Property | Description |
|---|---|
Type of VCS | Type of version control system supported by TeamCity: for example, Perforce or Subversion. |
VCS root name | Unique name of VCS root across all VCS roots of the project. |
VCS root ID | Unique ID of VCS root across all VCS roots in the system. VCS root ID can be used in parameter references to VCS root parameters and REST API. If not specified, will be generated automatically from VCS root parameters. |
Repository URL | URL to VCS repository. Supports URLs in different formats, like:
|
Minimum polling interval | Specifies how often TeamCity polls the VCS repository for VCS changes. By default, the global predefined server setting is used that can be modified on the Administration | Global Settings page. The interval time starts as soon as the last poll is finished on the per-VCS root basis. Here you can specify a custom interval for the current VCS root.
If TeamCity detects that a VCS commit hook is used to trigger checking for changes, this interval is automatically increased up to the predefined value (4 hours). If the periodical check finds changes undetected via the commit hook, the polling interval is reset to the specified minimum. |
Belongs to project | Each VCS root belongs to some project, and in this section the name of this project is displayed. A VCS root can be moved to the common parent project of all subprojects, build configurations and templates where the root is currently used. |
Refer to the pages inside this section for VCS-specific configuration details.
note
Make sure to synchronize the system time at the VCS server, TeamCity server and TeamCity agent (if agent-side checkout is used) if you use the following version control systems:
CVS
StarTeam (if the audit is disabled or the server version is older than 9.0)
Subversion repositories connected through externals to the main repository defined in the VCS root
VSS (all VSS clients and TeamCity server should have synchronized clocks)
Thanks for your feedback!