I strongly want this feature. If you want to run a build on both a branch and the trunk for project X it seems odd to have to configure two completely different projects, instead of two build configurations for the project.

If my understanding is correct this limits build configurations to a single line in the source tree which limits their functionality.

Example

=

svn://server/foo/trunk
svn://server/foo/branches/REL-1.2.7

I could setup a project with a VCS root of svn://server/foo and setup both build configurations under that, relative to trunk and branches/REL-1.2.7 but then the report of what files changed for a given build will include all the changes under the VCS root and not only files within the root that is relevant to that build configuration.

We also need this feature to arrange our build configs within projects in a way that makes sense to us.

Ideally, TeamCity would work this way. See the example projects & build configs below:
Project: Compile Build libraries Build Applications
build config: main =if successful do this => main =if successful do this => main
build config: dev1 =if successful do this => dev1 =if successful do this => dev1
build config: dev2 =if successful do this => dev2 =if successful do this => dev2

The main, dev1, dev2 configs represent Perforce branches.

So, what we would like is the ability to have each build config have its own SCM sandbox and the project simply be a container for the build configs.

Poll: what are your exact needs from this feature? How do you envision it's implementation so it is most suitable for you?

To be a bit more specific as to our needs from the Dec 06 post above:
We would like a project to be a container for a specific application/project with its build configs having the ability to build from different SCM branches. We would like to see something like what I have attached.

In response to the poll, I think something along the following lines would work well:

A project configuration may continue to have VCS roots.
Additionally, a build configuration may have VCS roots. If it does, both the project and build configuration VCS roots are used for builds.

This would allow something like the following:

Project: TeamCity

 Build Config: Agra Bug Fixes
 Build Config VCS: svn://svnserver/teamcity/branches/agra
 Build Config: Benares
 Build Config VCS: svn://svnserver/teamcity/trunk

The project is TeamCity in both cases but the build configuration determines where the source for the project is obtained. Without this feature, we have to do something more like:

Project: TeamCity Agra
Project VCS: svn://svnserver/teamcity/branches/agra
(build configs)

Project: TeamCity Benares
Project VCS: svn://svnserver/teamcity/trunk
(build configs)

which forces projects to be organized by release instead of project.

An important aspect would be that VCS roots can be configured independently and can be attached to several projects / build configs. We have several modules that are shared between different projects in different combinations, which currently requires a lot of redundant VCS root configurations that are a nightmare to maintain.

I've just read http://www.jetbrains.net/confluence/display/TCD3/Configuring+VCS+Settings and am getting worried that with TC 3.0 VCS roots *have* to be configured per build type. This is going to become a major headache for us because we share VCS roots between projects - each with at least two build configs. Maintaining the VCS roots per build config will be a nightmare.

Please consider adding the possibility to define VCS roots globally and use them in multiple projects/builds.

Sascha,

Current development version already has some support for the VCS roots sharing between projects. The draft documentation for the 3.0 version has some to catch up with the already implemented state.

Our current approach is as follows:
- VCS roots are to be specified as one of Build Configuration's setting
- One can either create new VCS root or select one of already used in other Build Configurations
- VCS roots can be marked as system-wide to become available to any Build Configuration withing TeamCity installation. If VCS root is not marked as system-wide, it can be reused in the scope of one project only.

How well does such approach suit your needs?

That sounds perfect, thanks!