Build config now shows "Active Branches" but haven't updated TC (and still using SVN)

I haven't upgraded Team City in a couple months; I'm running version 8.0.4. I have been running it against SVN the entire time.

Recently, I have seen two projects that now have an "Active Branches" dropdown. From the TC 8.0 Feature Branch documentation, I thought this was only supported under DCVS repositories like Git & Mercurial, and specifically NOT supported using Subversion.

I have made two changes that might have impacted this, but I'm not sure...


About a month ago, drastically reduced the branches and got rid of nesting.

    1. We had
      1. trunk,
      2. branches/1x/1000 Series/
        1. 1010/
        2. 1020/
        3. ...
    2. We now have:
      1. trunk
      2. branches/beta
      3. branches/legacy
      4. tags


In the build config in question (it is part of a chain), I changed the checkout rules.

  • There are two different Subversion repositories referenced; the main source, and the helpers.
  • I changed the helpers checkouts, dropping the leading /,
    • from:
      • /buildTools/SpecificToolsA
      • /buildTools/SpecifictToolsB
    • to
      • buildTools/SpecificToolsA
      • buildTools/SpecificToolsB


You'll see in the screenshot that this may be what triggered it, because there are the branches "default" and "+:buildTools/... -:buildTools/..." which makes me think it was making patch changes to the repos?

Anyway, here are my questions:

1. What triggered this? Was it the second set of changes I made?
2. Is there any way reliably to use the Active Branches / Feature Branches under Subversion? I'm guessing not...


More environment info:
TeamCity Enterprise 8.0.4 (build 27616)
Server & Build Agents: Windows Server 2012
SVN Repositories Version: 1.8



Attachment(s):
2014-01-03 11_50_18-c# Stack __ product beta __ 3.png
2 comments

Seems you're facing this issue: http://youtrack.jetbrains.com/issue/TW-26770 which will be fixed in 8.1. For now, if you have a single build with strange branch name, you can try to remove it from build history, see Build actions menu.

0

Hmm, interesting. Referring to the bug, where:

  1. Config A runs first,
  2. and Config B is the second step in the chain, dependent upon Config B...


In my case, it appeared in Config A, not B, but they probably are related.


Since then, I took an existing project that was targeting trunk and overrode the repository path to point to some specific tags (taken from trunk) and saw the same behavior, although the names look more like what they were supposed to.

0

Please sign in to leave a comment.