As much of the power of VSTS's new version control is the ability to merge all or parts of files across branches, I am suprised to be running into what seems to be a bit of a showstopper to my whole source control strategy.

I have various 'project' branches that were created from a mainline (lets say at the same time), so that work on the same system can be carried out in parallel but in isolation. Both 'projects' make changes to the same solution file. At the point at which both projects want to formally release their work, they both need to merge their respective changes back into the mainline.

The problem is that the sln file actually numbers each visual studio project that it contains and even has a count of the number pf vs projects in the source control section of the sln file, here is an example snippet:

SccTeamFoundationServer = xxxxxx

Simon,

I think you raise very painful point; I have found that it is very important when performing merges to check whether any solution/project files were merged. As generally there are no conflicts to resolve, I just manually review the merged solution/project before checking them in, to make sure that automatic merge changes make sense. It is not very elegant and certainly not automated, but much better than to discover that after merge the solution is broken.

I am curious how did you solve that issue. Any insights?

Thanks beforehand,

Eugene