The "Merge by Work Item" feature is quite harder to implement as I expected.
The main reason is the issues I encountered with the Source Control implementation in Team System.
I first wanted to rely on the GetMergeCandidates API to filter the changesets that were already merged between the two branches, only to find out several weeks later (and several forum posts and Email with MSFT) that this API is bugged, and doesn’t returned all the changeset it should !
Not cool…
I tried many things to solve this issue, and I finally came with a custom code that "complete" the result of this call, apparently I have now the full list of candidates, but man, it’s damn slow to compute!
Finally, when I thought everything was ok, I find out that it’s completely impossible to do two consecutive merges on the same file if I don’t do a check-in between them!
That’s it: you can’t do all your merge operations, then finally check the result in, you have to do one merge, one check-in, then loop to the next changeset to merge. I don’t know if I’m the only one, but I find this awful!
We want to use the "Merge by Work Item" feature to drive the making of our software release. This cycle happens every two weeks, and we can have 20 features (Change Requests or Bugs) made of 1-3 implementation Tasks each, with at least 1-3 changesets to each task. The reasonable number of changesets to merge is around 200!
Two hundred consecutive check-ins!!! Are you kidding me? By the way, I tried, and looks like spamming merge+checkin operations to the TFS server continuously doesn’t end up good!
I really hope Orcas will have several improvements on the branch/merge management, it’s good to have new high level features, but having the "good old low level" ones working perfectly is still for me the priority!
Here’s a little snapshot of the main form of the Merge by Work Item feature:
Profiles
