Calculation of "Changes" list



some background information first: we build from a single code base many different variants, let's say 30. For each variant, we have a specific build configuration: B1..B30. Since developers typically test on a single variant when they fix a bug, we have pre-merge checks to verify that didn't break another variant before a change is merged in the mainline ("master" in git). We call these "Pre-merge builds". We cannot afford to have all builds started as pre-merge, so we start only a subset, let's say B1..B4.

For that, we have a dedicated build configuration called "Pre-merge builds". It's triggered for changes on "review/*" branches. It has as snapshot dependencies: B1..B4.

We have also another build configuration called "All supported builds". It's triggered for changes on "master".

So the workflow is:
- developer creates a commit and pushes it to review/...
- "Pre-merge builds" is  triggered automatically on this commit, which in turns triggers automatically B1..B4 on the review/* branch
- the developer waits for feedback
- when the commit is approved, the commit is merged into "master"
- the "All supported builds" build configuration is triggered automatically, and triggers in turn B1..B30 on the "master" branch

The problem is that the "Changes" list of "Pre-merge builds" is not what I need. I would like to see there only changes between "master" and the "review" branch.

At first, I defined the same VCS roots in "Pre-merge builds" as in B1..B30, but then the list of changes was very long. I am not sure how it is calculated.
Then I tried to use the option "Triggers a build on changes in snapshot dependencies" in the trigger of the "Pre-merge builds", and therefore removed all VCS roots from it. But then the list of changes was empty.

It's not only a cosmetic issue, it causes concrete issues:
- VCS trigger rules in "Pre-Merge Builds" cannot work, for instance to exclude directories known to have no impact on the builds
- Email notifications are sent either to too many people, or noone, instead of the author of the one commit

Any help would be appreciated.



Hi Olivier,

Do I correctly understand that you want to see only changes on "review/*" branches in "Pre-Merge Builds"? If yes, then you can configure branch specification for VCS root attached to "Pre-Merge Builds". So only changes on "review/*" branches will be monitored and added to changes list in "Pre-Merge Builds".


Hello Alina,

thanks for your answer.

Currently, all build configurations are using the same VCS roots. If I want to change the branch specification for Pre-Merge, then I need to use dedicated VCS roots, don't I ?

In that case, Pre-Merge will have different VCS roots than B1..B4. Will then the snapshot dependencies work properly ? I always thought that to use snapshot dependencies, you need to use the exact same VCS roots.



You can use the same VCS root and configure branch specification using build configuration parameters.
You can use different VCS roots for build configurations with snapshot dependencies. If the VCS settings are different (VCS roots or checkout rules), then "same sources snapshot" revisions means revisions taken simultaneously at some moment in time.


Hi Alina,

thanks. I tried it out using dedicated VCS for Pre-Merge, I found so far 2 non-blocking issues.

First, since I watch only the review branches, and none of them is fixed, I don't have any "default branch" to enter in the VCS. I entered "dummy" as a workaround, Teamcity therefore displays an error, because it doesn't exist

Secundly, and more importantly: I still don't get how the "Changes" list is computed. Just after the configuration changes, I have pushed a commit on a review branch. The Pre-Merge Build was triggered as expected, but some dependencies in TC where showing 1 change, others 20 changes.
I amended my commit and pushed it again, then it showed "1 change", which is what I want. I will monitor how good it works in practice in the next days.

I still don't get how this "changes" list is computed. Is this documented precisely somewhere?



Hi Olivier,

1. Now it's not possible to create VCS root without default branch. Please vote for
2. > some dependencies in TC where showing 1 change, others 20 changes.

Could you please attach screenshots illustrating the issue?

I have sent a screenshot by email, you will see that the Pre-Merge build is reported to have 838 changes, and its dependencies either 0 or 1.


Seconding this issue. I wrote a comment on the ticket. I would like to be able to modify the way in which the `changes` view is calculated. Even a setting to just use the latest commit on the branch as the `change` would be better.


3 years later, I am now in a new environment, and I still have this problem. We have 3 layer of branches:

master -> feature -> review

The review branches are merged regularly in "feature", and at some point we will merge "feature" into "master". The "review" branches are tested automatically by Teamcity, and we want the developer of the review branch  to be notified by email in case of build errors, so we set a notification with "Builds with my changes only" set. The problem is that when there is a build issue, Teamcity considers all changes between "master" and "review", and will send a notification to all developers who contributed to the feature branch so far, creating unnecessary emails and confusion.

A quick fix would be an option to consider only the last change, as Jordan mentioned.


Please sign in to leave a comment.