Merge by Workitem
Allow users to select WorkItems and related changesets on Merge screen. Probably Merge candidate WIs will be required.
Oğuz Bayrakdar
shared this idea
12 comments
-
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
-
Shmulik
commented
You might found this blog post helpfull for your needs:
http://blogs.microsoft.co.il/blogs/shmuliksegal/archive/tags/WIMBI/default.aspx -
Could you at least support this feature in Power Tools ?
-
Lin
commented
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
Hi,
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
-
Hi Matt,
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.
Thanks
Oguz -
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)?
Matt
Program Manager | TFS Version Control -
Anonymous
commented
IBM Clearcase / Clearquest is suporting this feature for over years. And Jazz will too.
-
Mikey
commented
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
-
bebo
commented
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.
