Merge by Workitem
Allow users to select WorkItems and related changesets on Merge screen. Probably Merge candidate WIs will be required.
Thanks for the feedback on this idea. We have reviewed this feedback and determined that we will not be able to complete this suggestion in the foreseeable future.
TFS Program Manager
Here's how I want to use merge by work item:
Dev, QA, and Release branches in code. Each of these is set up to automatically deploy to the corresponding server environments. I gate merges to QA by work item. This way devs are free to get things into the Dev server build as needed. Only things that pass QA get merged by work item id to the release branch and thus bundled with the end of sprint deployment.
Without merge by work item, this process is painful and arguably impossible from a practical perspective.
There is a visual studio extension which appears to support work item based merges quite nicely and a few other neat things as well. It is a beta version currently, but looks promising.
Edvaldo de Oliveira commented
Edvaldo de Oliveira seu candidato para melhor aceleração na internet.
You can merge by Work Item in TFS/VS 2012. If you track the work item (like you can a changeset) you can use the visualisation to move it onto the next branch. see http://blogs.msdn.com/b/slange/archive/2012/07/11/vs-tfs-2012-tidbits-merging-changes-by-work-item.aspx
Only downside is you cant do this on multiple work items at once and also reporting/managing which branch(es) have which work items is non existant
Sarah Adler commented
Our team works by work item ids and we want a want to be able to say workitem ids 123, 234, 345 are going into build 7.8.2013.1. If we had merge by workitem we could easily merge all of the changesets related to those workitems and ensure the bulld contains the workitems and not have to translate workitems into changeset ids.
Rolf Kristensen commented
What is this madness, how can a version control system not keep track of what workitems has been released to production. And now I'm out of votes, because this **** VS2012 Team Explorer is a complete disaster. Arghhh
You might found this blog post helpfull for your needs:
Oğuz Bayrakdar commented
Could you at least support this feature in Power Tools ?
If you're not a Build Engineer you'll never understand how beneficial this feature would be. Unforntunately there are too few of us to really be heard. If I thought my congressman could help, I would write him.
Daniel Mackay commented
As merges can only currently be done at the changeset level, this encourages NOT checking into TFS regularly. Instead of doing many smaller check-ins a developer will instead hold back and do fewer but larger check-ins so that all the work is in a single changeset. This makes merging easier, but discourages regular check-ins. :-(
Mattias Sköld commented
@Matthew Mitrik - Ive seen several teams working with Stories and task during a sprint, in the dev branch, and by the end of the spritn after story approval, they merge each approved Story into the main branch. Doing so takes a lot of time and effort away form productivity.
Paulo Ferro commented
This actually is one of the most time-saving features lacking in the product.
The real cases can be any, the customer asks for a full version and there goes a full merge, or the customer gives a list of which features (Work Items) would like to see in the new version.
The challenge of merging is not much, I think, the problem is that WIs are associated to the original branch and there will probabily be only one changeset with all changesets merged, so all WIs will be associated with this WI. From my point of view there should always be kept the original chengeset/WI association, if I have to do another merge of such WI there should only be the original changesets being merged. Even if it makes me merge allways from the original branch to the new destination branch or something.
I'm not sure if my answer was clear but hope it helps in any way.
Best regards and thanks for the great product
Oğuz Bayrakdar commented
Our developers are tracking thair daily jobs with WIs and yes they want to merge their features instead of changesets. For example two or three developers can code for a single feature. At the end of feature development they will have a single WI with 3 or more change sets for feature. Than they will want to merge single feature WI instead of 3 or more change sets.
Matthew Mitrik commented
This is something that we're tracking on our product backlog, and I hope to make a more holistic improvement to the merge experience in the future. The current wizard approach is very limiting, and in order to better facilitate more advanced features like merging by work item and cherry-pick merging, we need something better.
I'd love to hear examples of how people would like to use merge by work item. Would you use it to merge all of your features? Or would it be used only when porting select changes (i.e. bug fixes)?
Program Manager | TFS Version Control
IBM Clearcase / Clearquest is suporting this feature for over years. And Jazz will too.
There is a product to merge by Wı but it is still beta and i think it is complicating the merge process instead of making it easier. http://www.sela.co.il/alm/products_Wimbi.html
This is a great idea. I wonder if this tool would be helpful. It is AFTER the fact, but we have found it helpful to make sure the appropriate work items get associated with our merge changesets: http://geekswithblogs.net/jakob/archive/2011/05/17/automatically-merging-work-items-in-tfs-2010.aspx.