The VCS Checkout mode is a configuration that sets how project sources reach an agent.
Please note that this mode affects only sources checkout. Current revision and changes data retrieving logic is executed by the TeamCity server and thus TeamCity server should have access to VCS server in any mode.
Agents do not need any additional software for automatic checkout modes.
TeamCity has three different VCS checkout modes:
| Checkout mode
| Automatically on server
|| This is the default setting. The TeamCity server will export the sources and pass them to an agent before each build. Since sources are exported rather than checked out, no administrative data is stored in the file system and version control operations (like check in or label or update) can not be preformed from the agent. TeamCity optimizes communications with the VCS servers by caching the sources and retrieving from the VCS server only the necessary changes (read more on that). Unless clean checkout is performed, server sends to the agent incremental patches to update only the files changed since the last build on the agnet in the given checkout directory.
|Note about usage|
- Server side checkout simplifies administration overhead. Using this checkout mode you need to install VCS client software on the server only (applicable to Perforce, Mercurial, TFS, Clearcase, VSS). Network access to VCS repository can also be opened to the server only. Thus, if you want to control who has access to the source repositories, server side checkout is usually more effective.
- Note that in some cases this checkout mode can lower load produced on VCS repositories, especially if Clean Checkout is performed often, due to the caching of clean patches by the server.
- Note that in server checkout mode the administration directories (like .svn, CVS) are not created on the agent.
| Automatically on agent
|| The build agent will check out the sources before the build. This checkout mode is supported only for CVS, Subversion, TFS, Mercurial and Git (since TeamCity 5.1.1). Agent-side checkout frees more server resources and provides the ability to access version control-specific directories (.svn, CVS); that is, the build script can perform VCS operations (like check-ins into the version control) — in this case please ensure the build script uses necessary credentials for the check-in.
- Agent checkout is usually more effective with regard to data transfers and VCS server communications. As long as agent side checkout is just a source update or checkout, it creates necessary administration directories (like .svn, CVS), and thus allows you to communicate with the repository from the build: commit changes and so on.
- Machine-specific settings (like configuring SSL communications, etc.) should be configured on each machine using agent-side checkout.
- "Exclude" VCS Checkout Rules cannot improve agent checkout performance because it checks out the entire top-level directory included into a build, then deletes the files that were excluded.
- Certain version controls can provide additional options when agent-side checkout is used. For example, Subversion.
| Do not check out files automatically
|| TeamCity will not check out any sources. The build script should contain the commands to check out the sources. Please note that TeamCity will accurately report changes only if the checkout is performed on the revision specified by the build.vcs.number.* properties passed into the build.