VCS (版本控制系統) 是用來跟蹤項目源文件版本變化的系統。它還有其它的名字，比如 SCM(源代碼管理)。當前 TeamCity 內置支持的 VCS 類型有：Git, Subversion, Mercurial, Perforce, Team Foundation Server, CVS, StarTeam, ClearCase, SourceGear Vault, Visual SourceSafe。
本文將通過實例比較詳細的介紹 Build 中版本控制系統的設置。
VCS root
一個 VCS root 定義了一個到版本控制系統的連接，這個連接包含了 TeamCity 和版本控制系統通信的所有信息(源文件路徑, 用戶名, 密碼和其它設置)。有了這些信息，TeamCity 就可以監控代碼的變化並且在做 build 時把代碼獲得到本地。您創建的 VCS root 必須屬於某個項目，它可以被這個項目和這個項目的子項目中的 build 使用。
創建 VCS root
您可以點擊 “Attach VCS root” 按鈕開始 VCS root 的創建過程：
選擇您的 VCS 類型，點擊 “Create” 按鈕：
VCS 類型
TeamCity 內置支持了主流的 VCS :
您可以選擇您使用的 VCS 的類型，然后按照提示完成 VCS root的創建。接下來筆者將通過一個實例來說明一些細節。VCS 的類型就選擇筆者使用的 TFS (好土啊，居然還沒用上 Git!)。
VCS root 名稱
VCS root 名稱需要是唯一的，以區分不同的 VCS root，我們在引用 VCS root 時就是通過這個唯一的名稱：
VCS root ID
VCS root ID 也必須是唯一的，它會被 TeamCity 內部的程序引用，也可以被用作 REST API 的參數。一般我們不需要手動指定它，TeamCity 會按照下面的規則自動生成：
項目名稱 + 下划線 + VCS root名稱。
VCS URL
指向 VCS 的 URL，填寫您取代碼的地址，如：
代碼路徑
指定從代碼庫中獲取代碼的路徑：
用戶名和密碼
從代碼庫獲取代碼時提供的認證信息：
強制獲取所有文件
這是 TFS 相關的一個選項，當 TeamCity 通過 Build Agent 獲取代碼時這個選項會起作用。當選中 “Enforce overwrite all files” 時，TeamCity 會通過 請求 TFS 更新所有的文件。一般情況下您是不需要這么做的。當然，有時您可能會懷疑 TeamCity 沒有從 TFS 上獲取代碼，那時您就可以使用這個選項：
最小的檢查間隔時間
這個選項指出 TeamCity 多長時間檢查一次 VCS 庫的變化。默認情況下使用的是從系統繼承來的值。在 Administration | Global Settings 頁面有系統級別的設置。如果您要自定義這個值，可以選擇 custom進行設置。
所屬項目
在這里您可以指定當前創建的 VCS root 屬於哪個項目：
檢查連接情況
您可以在完成創建前檢查當前的配置是否可以正確的連接到 VCS，點擊 “Test connection” 按鈕進行測試：
連接成功的樣子：
下面點擊 “Create” 按鈕完成 VCS root的創建。
配置 VCS root Checkout Rules
我們可以為 VCS root 指定適當的規則，從而控制取到的代碼在 build 時的路徑。VCS Checkout Rules 允許我們獲取庫中部分的代碼，並且可以映射到 Build Agent 上的指定目錄。
具體的語法請參考《TeamCity : Build 基本配置》一文中的 Artifact paths 小節。
注意，Checkout 規則只能指定目錄不能指定單個文件，也不能使用統配符。
VCS checkout mode
VCS checkout mode 用來指定源代碼文件到達 Build Agent 的方式。從版本 10 開始 TeamCity 支持四種類型的 VCS checkout mode：
Prefer to checkout files on agent
這種方式是最新添加的，也是推薦的默認設置。取代碼的方式為先嘗試從 Build Agent 上向版本庫請求代碼，如果不行，再從 TeamCity Server 上嘗試。
Always checkout files on server
總是嘗試從 TeamCity Server上請求版本庫，然后把代碼發送到 Build Agent 上。
Always checkout files on agent
總是嘗試從 Build Agent 上向版本庫請求代碼，這種方式的好處是 Build Agent 上有完整的工作區，您可以在 Build 的過程中調用版本庫的命令。
Do not check out files automatically
這種模式下執行 Build 前是不會從版本庫獲取代碼的，主要用於調試。比如您可以在 Build 目錄中進行文件的修改，然后啟動一次 Build，從而驗證您的變更。
Checkout directory
默認情況下，Build 在 Build Agent 上的工作目錄是被 TeamCity 控制的。但您可以通過設置 Checkout directory 項為 Custom path 來自行控制 Build 的工作目錄：
個人感覺 TeamCity 默認的選項已經很好了，除非必要，否則不要自己指定這個選項。
Clean build
如果您有需求必須再每次 Build 之前清空 Build 的工作目錄，那么您可以通過設置 Clean build 選項來達到目的：
Display options
允許顯示來自 snapshot dependencies 的變更：
總結
Build 中版本控制系統的配置的重要性無須多言，好在 TeamCity 提供了比較靈活多樣的配置方式，讓我們可以簡單便捷的實現各種用例。