CODEWITHSUNDEEP
tfsworkspacebranching-and-merging
bwerks
bwerks

Reputation: 8981

Collaborative merge conflict resolution in TFS 2010

I'm responsible for doing some significant forward-integration on a branch that I'm not too familiar with. I'm comfortable merging the majority of the conflicts, but there are some areas that I would really like to be done for me to mitigate the risk of a merge errors. We're running on Tfs 2010: what are my options?

Our normal workflow for communicating changes between developers it to use shelvesets, but Tfs disallows shelving of files before merge conflicts are resolved...which is unfortunate if it's the merge conflicts themselves that I want to pass around. I know Tfs 2010 introduced the idea of a shared workspace--can this feature be used for multiple people to resolve merge conflicts in place?

We have a geographically distributed team, so unfortunately we can't just walk over to each others' desks. If shared workspaces won't help me achieve this goal, what are my options?

Upvotes: 2

Views: 865

Answers (1)

Mike Veigel
Mike Veigel

Reputation: 3815

Our team will typically pass off that section to merge to the developer who primarily worked on it assuming it is self-contained (IE merges here will not break code inside a sln). Then, once complete, the rest of the merge will take place. Sure it is two steps; however, it ensures the merge is done correctly.

In the cases where that is not an option, we typically have the person in charge of the merge take note of the file or files he isn't 100% sure about and then after merging, and making sure of course that the project builds, he IMs / Emails the team with the list of files and asks the people who primarily worked on that code to review the changes. Granted, this process isn't full-proof but it is at least how we have been handling it.

Another solution, as you eluded to, would be to have a TFS shared workspace that lives on a server that all of your team can remote into and review the code. Here is a good article describing how to set that up. If everyone is using the same shared workspace/mappings etcetera, it is easier to do a joint merge.

And finally, one last option that comes to mind is opt to keep the local version (do not merge up the file) assuming it will not break the build and then pass it off to another developer. That developer, using TF Merge /force can force a merge that will pickup the fact that you opted to keep the local version at which time the additional developer could resolve those merge conflicts.

Shelving and Unshelving is there for code reviews which is why there isn't support for conflict resolution. Or as MS states:

Unlike the Get operation, which merges reconcilable differences between two versions of a file automatically and helps you merge conflicts manually, the unshelve operation does not support merges. By removing shelved pending changes from your workspace at the commencement of the code review, you can be assured that any changes that your reviewer makes to the shelveset, such as adding comments to a file, do not create merge conflicts during the unshelve process.

I understand why they are doing this but I do agree with you that it would be nice to have a shelve "type" that was of type Merge or something to that affect. It would surely help out when working with large projects with complicated merges.

Upvotes: 2

Related Questions