Best practice for merging solution files with project id conflicts

Question

Suppose that the TFS branch was created from some main branch that had 2 projects (FirstNewProject), but while work continued in this branch, another branch (SecondNewProject) was created, the task was completed and that the other branch was merged back.

If we try to merge this first branch back into the main branch from which both of these branches were forked, we now have a conflict in the solution file, which, apparently, can only be resolved manually ...

The first conflict with the variable SccNumberOfProjects = 3 TFS, which is the same in the FirstNewProject and SecondNewProject decision files, but needs to be changed to SccNumberOfProjects = 4 , because when SecondNewProject was merged back, the number of projects was 3, but now that we "Merge FirstNewProject quantity 4 projects now.

Would you change this variable manually to 4, creating an invalid solution file?

The second conflict is in the Global section, and it is associated with the numbering of projects.

SecondNewProject added these lines to the solution file:

 SccProjectUniqueName3 = SecondNewProject\\SecondNewProject.csproj SccProjectName3 = SecondNewProject SccLocalPath3 = SecondNewProject 

FirstNewProject added these lines to the solution file:

 SccProjectUniqueName3 = FirstNewProject\\FirstNewProject.csproj SccProjectName3 = FirstNewProject SccLocalPath3 = FirstNewProject 

But FirstNewProject is now the 4th project, so we need to change these entries to

 SccProjectUniqueName4 = FirstNewProject\\FirstNewProject.csproj SccProjectName4 = FirstNewProject SccLocalPath4 = FirstNewProject 

manually, and this will invalidate the solution file, and is there anything else if you go in a situation like this?

Answer 1

Assuming your branch structure is similar:

  FirstNewProject / Main branch \ SecondNewProject 

Now you have edited both in FirstNewProject and SecondNewProject and you want to combine FirstNewProject into Main Branch, as well as SecondNewProject. SccNumberOfProjects in SecondNewProject is 3 and SccNumberOfProjects in FirstNewProject is 4, so you confuse SccNumberOfProjects in the main branch should be 3 or 4, right?

I'm not sure why you asked that changing SccNumberOfProjects would invalidate the solution file. Since you are merging between the Main branch and the other branches, the source branch and the target branch should be the same.

In terms of Branch and Merge strategies, the base branch plan should look like the following screenshot:

The main branch is the connection branch between the development and release branches. This branch should be a stable snapshot of the product that can be shared with QA or external teams. To unblock a branch is to isolate the code in preparation for release. And all changes must occur in the development branch. When the code works well in the Development branch, merge it into the main branch. When you want to release a solution, merge it from the main branch to the Release branch.

For your scenario, you need to check which branch you want and change the branch to resolve the conflict. You can then follow the branch strategy to manage your branches.

Answer 2

Merging sln is a scary experience. However, I see another solution to this problem: why not save the local version, and then manually add a new project to it (from visual studio). I know this manual, but much less error prone