This project has moved and is read-only. For the latest updates, please go here.

associating changeset per branch using Team Build in TFS 2010

Jun 4, 2012 at 1:46 PM
Edited Jun 4, 2012 at 1:47 PM

Hi all!

I have a problem which I'll describe very shortly. I have a project with 2 branches now and each one has its own build definition. May be anybody knows how to divide associated changeset by branches, because TFS default build process template associates all the changesets to successful build of every my branch.

When I ask how I mean that is there any way without coding my own custom activities and so on. I have seen VersionControlServer.QueryHistory method on MSDN And I can see that it takes the path in source control repository to find the changesets. And as I've understood standard activity AssociateChangesetsAndWorkItems uses that method and takes the whole project path while I need only part of the project repository. But AssociateChangesetsAndWorkItems has no way to manage it, so now I think the only way is to code my own activity and to provide each build definition with a subpath to search. I don't like this solution so I hope somebody can help me to find better solution.

Thank you very much!

Jun 4, 2012 at 4:44 PM

Maybe I'm misunderstanding the question, but are you asking how to see just the associated changesets for your particular branch in your build summary and reports?  Check your workspace mapping for your build, just make sure you are mapping to the branch itself for each of your builds, and not the root of the team project.  Then when you run your build you should only see the associated changesets for that particular branch.  (not something in some other area of version control)

If I'm misunderstanding your questions, please let me know and we can go from there :).


Mike Learned.

Jun 4, 2012 at 6:27 PM

Thank you Mike for quick reply.

I'll refine my question. I have a folder/branch structure like this:

  • root
    • shared_project1
    • shared_project2
    • branches
      • branch1
      • branch2

So as you can see I have some projects shared between my branches which I prefer not to branch because they have their own branching and release strategy. And when I build this project using Team Build I have just the same workspace for both branches, but I have 2 different solutions for each branch and reference that solution files from build definition which actually are the same. So branches share the same workspace but each have its own solution file which collects all the projects (shared and private for branch). And of course when I build each build definition I have shared list of associated work items.

If this approach is wrong I'm ready to change it for a better one, but give me a hint how.

Thank you very much.

Jun 6, 2012 at 6:19 PM

Right so that structure works fine, but in your build definition you need to make your worksapce map just to "branch1" as an example (not branches or above) if you want the associated changesets to work correctly.  There would also be other ramifications have having your workspace mapping "too high" such as gated check-in and CI issues if you were using those as well.  Also it is bringing down more data to the build server each time causing network perf overhead, etc...based on your mapping.  The developer workspaces won't matter for this, I'm talking about the build definition workspace.

Only map your build definitions workspaces to the node (no higher or lower) for the solution(s) you intend to build.  The option to choose the correct solution is just telling the build to build that particular one, but you are fooling the system in other ways I mention above.

I assume there is no need to build branch1 and branch2 at the same time?  If there was then I would map to the branches folder above, but would have to live with the things I mention above about associated changesets, gated, CI, etc.

Does it make sense?

Jun 6, 2012 at 6:23 PM

I should also mention about your "sharing"....  is the solution in branch1 or branch2 relying on a shared_project1 or shared_project2 as a project reference to do a build?  Or are you building the output and referencing it like a DLL or something with a file reference?  BTW in the guide we talk about "Sharing Resources" in TFS.  The Beta has some coverage, and it will be refined in the RC.

If you are using like project references, and those projects "shared_project1" etc are living in the same solution as branch1 solution then yes we need to reconsider the structures and strategy perhaps.

Jun 6, 2012 at 7:05 PM

Mike, thank you very much for your attention to my problem.

Of course there is no need to build branches together. Actually I've asked the same question at Microsoft's social at 

The solution mentioned there is suitable for me and I've alredy marked it as helpful. The deсision is to "cloak" unused folder (unused branch in our case) and then everything works fine. And all the issues you mentioned (network load for example) are also addressed very well with that decision. One of the powerful goals of this approach is that changesets in shared projects are associated during the build of both branches. But private changes are associated only to particular branch.

I haven't understood how the problem correlates to gated check-in and CI? I'll be very glad if you make it clear.

To continue discussion I can tell that my shared projects are built during the build of other non-shared dependent projects and then I yield binaries and use them in the build of dependent projects. All is done via MSBuild and works perfect. I use no project references, I build shared projects directly from MSBuild script because it is more suitable as I think in my situation.

What is BTW?

Thank you in advance.

Jun 8, 2012 at 2:38 PM
Edited Jun 8, 2012 at 2:40 PM

The problem with CI and Gated check-in is again all based on workspace mappings.  If you for example had a mapping for build definition of $/TeamProject  then every check-in under that team project would get kicked off for CI or be monitored for Gated check-in, when you might want just some single branch to be so for that build def.  Never map any higher or lower than needed for your build.

"BTW" = By the way  :).