When displaying changes included in a finished or queued build, TeamCity also displays the corresponding revision. This page explains how TeamCity chooses VCS revisions for a build.
After that, TeamCity does not monitor the whole repository but only collects changes for the scope of the repository specified in TeamCity: the configured VCSルート設定 with checkout rules.
The revision of the sources corresponding to the latest detected change affecting your build will be displayed as the VCS root revision on the 変更ページ accessible via the link on the プロジェクト page or on the 変更タブ of ビルド結果。
On detecting a new commit in any VCS root, TeamCity assigns this commit to an incrementally increasing internal ID. All detected commits on the TeamCity server are sorted by these IDs.
When starting a build, TeamCity scans VCS roots of the build and, for each root, checks out the revision that corresponds to the commit with the latest ID, according to the internal sorting. This way, TeamCity orders source revisions based on the ID of their latest commits.
This is used, for example, to set apart a history build that is a build which highest-ordered revision has a lower order than any build that run earlier.
Revision change on modifying VCS root
If the settings of a VCS root get modified since the last detected change, the revision in TeamCity will be different from the last change in the newly configured VCS root. TeamCity does not have any information on the previous change in this new root, so it starts to monitor changes with the new settings and sets the build revision to the first discovered change. Until the change is discovered, there is no way to get any revision other than the current revision of the repository. Therefore, while TeamCity builds the correct revision of the sources, the revision for the first build after a VCS root change will not be equal to the last change under the specified path.