Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Best practice for merging solution files with project id conflicts

Let's say a TFS branch was created out of some main branch which had 2 projects (FirstNewProject) but while the work was still ongoing in that branch, another branch was created (SecondNewProject) the task was finished and that other branch was merged back down.

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

The first conflict is with SccNumberOfProjects = 3 TFS variable which is the same in both FirstNewProject and SecondNewProject solution files but needs to be changed to SccNumberOfProjects = 4 because when SecondNewProject was merged back down the number of projects was 3 but now that we're merging the FirstNewProject the number of projects is now 4.

Would changing this variable manually to 4 create an invalid solution file?

The second conflict is within Global section and it has to do with project numbering.

SecondNewProject added these lines to solution file:

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

FirstNewProject added these lines to solution file:

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

But FirstNewProject is now 4th project so should we change these entries to

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

manually and will that make the solution file invalid and is there anything else to be done when merging back down in a situation like this one?

like image 495
Dean Kuga Avatar asked Feb 02 '16 01:02

Dean Kuga


People also ask

How do you resolve conflicts to prevent automatic merging?

Automatic merge failed; fix conflicts and then commit the result. At least one source branch change conflicts with a target branch change. Git halts the merge and waits for you to resolve the merge conflicts. Cancel the merge by running git merge --abort , or resolve all merge conflicts then run git merge --continue .


2 Answers

Merging sln is terrible experience. However i see another solution to this problem - why not Keep local version and then manually add new project to it (from visual studio). I know this is manual but it is much less error prone

like image 77
MichalMa Avatar answered Sep 19 '22 12:09

MichalMa


Assuming your branch structure is like:

 FirstNewProject
/ 
Main branch
\
 SecondNewProject

Now you have edited in both FirstNewProject and SecondNewProject, and want to merge FirstNewProject to Main branch, as well as SecondNewProject. The SccNumberOfProjects in SecondNewProject is 3, while SccNumberOfProjects in FirstNewProject is 4, so you are confusing SccNumberOfProjects in Main branch should be 3 or 4, correct?

I'm not sure why you asked changing SccNumberOfProjects would make the solution file invalid. Since you perform merge between Main branch and other branchs, the source branch and target branch should be the same.

In terms of Branch and Merge strategies, a basic branch plan should look like as the following screenshot shows:

enter image description here

Main branch is the junction branch between the development and release branches. This branch should represent a stable snapshot of the product that can be shared with QA or external teams. Release branch is to to isolate code in preparation for a release. And all changes should happen on the Development branch. When the code works well in Development branch, merge it to Main branch. When you want to release the solution, merge from Main branch to Release branch.

For your scenario, you need to check which branch is you want, and modify the branch to solve the conflict. Then you can follow the branch strategy to manage your branches.

like image 20
Cece Dong - MSFT Avatar answered Sep 19 '22 12:09

Cece Dong - MSFT