What does TFS merge uses: local or latest?
Recently our team got this question asked through the forums, and since I remember when we were making this decision, I thought it would be best to put it in paper and do a quick blog.
First let’s talk about the scenario: I have a workspace and I have not done a GET in a week or so but I want to merge a parent branch, which I have mapped, to my private branch. The question then is: would merge use my local workspace contents for the source or would it use the latest on the server? In addition, what does it use for the target?
When discussing this model we need to look at the intent of the customer. Do they want to merge the changes they have in their workspace to the target location? After careful analysis the answer to this question comes back as NO. They want to merge the contents of the branch. Since they want to merge the contents in the branch then it makes sense that for Source we always default to use the latest committed version and never pay attention to the contents the user has in their local. Effectively we assume that in a merge operation it never makes sense (unless the user specifies a workspace version range) to utilize the local source versions (which might not be even committed) and merge them to a target.
Summary: Merge uses Latest committed server version for the source of the merge
Now lets look at the target. In this case we need to pend the changes so this requires that you have the target mapped in your local. Going back to the scenario we ask the same question: what does the user wants to accomplish? We get two high level scenarios:
1. The user wants to bring certain changes (cherry pick or a range) from a branch into his local stabilize those changes and then integrate with whatever is latest
or
2. The user wants to do a catch up merge and is not interested in doing any integration with their local changes
On both of these cases we need to pend the change and have it reside on the user's local workspace. Due to this "requirement", looking at the server version is not ideal because we can easily put the users target workspace in an inconsistent state since some files will have new server content (participating in the merge) and other ones will not. Updating content for the user without an explicit Get action is always a recipe for disaster if the operation has a tendency to be partial on the items being updated. Keeping people from getting into this dependency mess is the main driver of our decision.
Summary: Merge uses local (workspace version) for the target of the merge
Regardless of this decision we always advice our customers to perform a Get in the target if they are going to be doing a catch up or big merge so they minimize the conflicts at check-in time.
There you have it ... hopefully you can use this information to make better decisions or to train your team in some of the TFS concepts.
- mario
Comments
Anonymous
May 06, 2008
PingBack from http://www.basketballs-sports.info/better-basketball/?p=967Anonymous
May 12, 2008
Lou Vega on Visual Studio 2008 Performance Analysis Tip. MRod on What does TFS merge uses: local or...Anonymous
February 12, 2009
The modal dialogs appear to be very confusing because they change language used from modal to modal. One moment their referring to source and target and then in a modal off that the reference is to local vs server. Just how muddled can you make it? Could we not have consistent language from one modal to the other? I'm sure the designer knew in their heads what they meant, but remember there are users out there and we're not all mind readers.Anonymous
February 12, 2009
The comment has been removedAnonymous
May 20, 2009
Thanks for explaining it. We just observed the "Merge uses local" and our initial reaction was "that's not right". At least we know the rationale.