Feature branch support for Subversion and Perforce

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:

Screen Shot 2012-08-27 at 5.07.33 PM.png

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.

Screen Shot 2012-08-27 at 5.07.04 PM.png

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?

Comment actions Permalink

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.

Comment actions Permalink

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?

Comment actions Permalink

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

Comment actions Permalink

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:

//project/%branch%/... //team-city-agent/...

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:

Parameters were changed in this custom build and these changes affect build version control settings (VCS roots and/or checkout rules).
To distinguish this custom build from regular builds it will be given the following automatically generated branch name: "/Main/..."".
If you want to change this branch name you can specify it in configuration parameter: "teamcity.build.branch".

Click "Ok" to continue and run the build with auto-generated branch name.
Click "Cancel" to return to custom build dialog.

If I accepted this, the branch was created with the name /Main/..." (note the mismatched closing double quote).

So I tried the recommendation and altered the VCS root and the custom parameter to use %teamcity.build.branch% and this resulted in a branch with the name 'Main' or 'Branches/branch1' which was slightly better, although not much different.  This time I also set a default value for the parameter to 'Main'.

Overall I'd describe this "solution" as halfway there, but not usable in practice due to the following constraints:
  1. VCS triggers only worked using the default parameter value.
  2. There was no concept of the <default> branch.
  3. The build.vcs.number seemed to relate to the /Main/... directory rather than the actual directory
  4. The branch names were ugly (it included the Branches/ part of the directory name)
  5. All branches had to be specified explicitly using custom builds

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.

Comment actions Permalink

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


Please sign in to leave a comment.