Discussion about this feature, as mentioned at http://youtrack.jetbrains.com/issue/TW-18911
Currently (at least in subversion) we can re-use the same build configuration for multiple branches by using a build parameter in the repository url, such as this:
This way we can ask TeamCity to build from different branches in the Custom Build Run dialog:
Seems that TC 7.1 already detects this pattern and shows branch info on the build status, altought I don't know why it shows in the xxx;xxx format.
So seems that some superficial support is there, but still far away from the Git or Hg, for example it will be better to choose which branch in a custom tab instead of relying on this customized parameter.
Anyone with experience with Perforce can please add some information, maybe something related to streams?
One possibility here would be to specify a pattern for the Subversion repository path - http://myserver/svn/projects/my_app/branches/(branch)/.* - this would mean you could watch the /projects/my_app/ folder for any changes, and when a change is detected whose checkin path matches the pattern, TeamCity could extract the branch name based on that pattern and use that in the builds and reports just as it does with Git.
I like the pattern idea, but to take care of the default Subversion repository structure, it should be possible to map them - something like this:
If the repository has a trunk at /repo/trunk and three branches at /repo/branches/feature1, /repo/branches/repo2, /repo/branches/repo3, the list of selectable branches will be "trunk", "feature1", "feature2" and "feature3".
What about VCS build triggers?
Inded. Working with a Wildcard approach seems to be simple enough. And while there's no established practice in regards to feature branches in Subversion, other than to put them into a 'branches' sub-folder, if need be, it would be very easy to add a nesting leve for feature branches, e.g.
to make them easily distinguishable and associate them with a specific build configuration (e.g. the oen for the project's trunk).
From a naive POV, it feels like this could be accomplished easily enough with a wildcard pattern and TeamCity searching the folders when there's a new commit detected at the first folder above the wildcard.
From a feature-POV, Subversion is becoming more powerful (faster, easier merging) with each new version. And while it's true that DVCS are the new cool kids on the block, not every established project needs to be switched to GIT (or will switch to GIT). Doesn't mean the developers of those projects aren't agile, use feature branches, etc. It just means, they are co-located and don't have merge conflicts painful enough to warrent a migration.
Best Regards, Michael
I tried this out today on our (non-streams) Perforce based project and it seems to work in the same way as you've described. I wouldn't describe it as usable as-is though.
In our Perforce depot configuration we use the following directory structure to manage branches:
In my experiment in TeamCity I created a new project and configured its VCS root client mapping as:
and set up a project-wide build configuration parameter 'branch'.
I ran a custom-build and explicitly set the build configuration parameter to 'Main', and then to 'Branches/branch1' and both 'worked'. TeamCity gives the following message:
However looking at the UI in TeamCity VCS roots for branch management for git and mercurial, whereby a branch specification and default branch are specified, and also looking at several of the pattern matching ideas in this thread, it looks like the above limitations could all be handled similarly to give usable feature branch support for Perforce or other directory-based systems.
Does anyone know if there's a way to tell teamcity to not detect the pattern. It seems to really mess things up in terms of tracking changes in different branches. I submitted a bug, but I'd be happy to just disable the detection. http://youtrack.jetbrains.com/issue/TW-31711