The Baseless Merge it is in the TFS 2012 integrated in merging wizard-
First I would like to say this should be avoided if at all possible. Having a relationship between branches makes it much easier to deal with branching. So unless you absolutely have to merge between unrelated related branches try not to.
What you need to know, TFS does not automatically create a merge relationship between two sibling branches (that share the same parent). This is by design. The VSTS Rangers Guidance II suggests avoiding baseless merges for normal merging scenarios.
The best way to merge changes from sibling (source) to another sibling (target) branch is to RI the change first to the parent branch and then FI the change to the sibling (target) branch. A huge risk with doing a sibling->sibling merge is that future siblings (which branch from the same parent) won’t have the change since it was never RI’d back to the parent branch.
As you know, baseless merges introduce a myriad of problems including:
- Conflicts cannot be auto-merged
- Deletes are not propagated
Now that disclaimers are out of the way, what is a baseless merge?
Take the following branch hierarchy. Dev can be merged with QA, and QA can be merged with hotfix or Prod. If you tried to merge a change from hotfix directly to Dev the UI will not let you. There is no relationship between them therefore it would be a baseless merge.
If I were to make a change in the Hotfix branch and attempt to merge it with Dev that option would not be available. As you can see in the merge dialog below the only option available for merging is the QA branch.
If I was to merge changeset 108 from Hotfix to QA the visualizer would show something like this.
If I wanted to merge the latest version of HotFix into Dev skipping QA I would have to do a Baseless merge from the command line. Using the baseless switch on the tf merge command.
tf merge /recursive /baseless Hotfix Dev
If we then take a look at the visualizer we can see that we did a baseless merge denoted by the dotted line.
TFS 2012 View of branching
Baseless merge in the UI – Another long standing piece of feed
back is people want to be able to initiate baseless merges in the UI. We’ve supported it in the command line for a long time but much as I said about rollback in my post on the Power Tools, for many people, if it’s not in the UI, it’s not in the product. Now it’s in the UI. If you initiate a merge from the Source Control Explorer, the merge wizard now has a browse button that allows you to go find branches to do a baseless merge against.
Let’s look at an example. I started with a branch structure that looked like this:
As you can see there’s no merge relationship between destination and AlternateDestination. But let’s imagine that I have some changes in destination that I want in AlternateDestination but I don’t want to go through Source. I want a baseless merge from destination to AlternateDestination. I can now go to Source Control Explorer and start the standard merge experience:
As always, only Source is in the list because it is the only related branch to destination. However, unlike TFS 2010, there is now a Browse… button for baseless merges. If you click it, you get:
and here you can see I can pick AlternateDestination. And if I do, and hit OK, I go back to the wizard:
And it warns me that I’m doing a baseless merge but I can hit next and then finish and proceed with it. So, now you can do baseless merges in the UI!
Merge on unshelve – From the beginning people have loved shelving as a simple, clean way to package up changes and set them aside. However, we’ve often heard the complaint that the inability to unshelve into a workspace with pending changes and deal with the merge conflicts was a serious limitation. No more! We have now built merging into unshelve operation and it works just like merging does elsewhere in the product.
This post has gotten plenty long so I’m not going to include screenshots of this. The new thing is that merges are performed, conflicts are filed, etc in this scenario. All the UI around that is the same as on other scenarios (like merge and get) where merges happen.