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 提供了比較靈活多樣的配置方式，讓我們可以簡單便捷的實現各種用例。