Geek Answers Handbook

Visual Studio 2008: how to avoid hell merge project file?

When you work on a VS C # project with several developers who all add new projects and files to the same solution, the last one who tries to check their changes gets conflicts in the project decision file, which are not easy to merge.

The easiest solution I have found to this problem is to reject my own changes and accept the latest version of the server. Then I reintegrate my changes. Depending on the number of new files added to the project, this can be simple or very unpleasant.

I am wondering if there is an easier way to do this. Read: can I do VS / TFS / merge do this for me?

+6
merge tfs visual-studio-2008 solution
source share
5 answers

My suggestion would be to update and commit more often. In particular, make sure you run Get Latest before waiting for any changes to the solution file.

Combining hell with things like XML and text files (all project files and solutions) usually only happens because people are trying to make very big changes.

If you get used to making regular commits, merges are usually smaller, and tools tend to do an excellent job.

+18
source share

I specially developed a tool for comparing / merging a solution file (and can also be used to dynamically create a filtered solution).

It can be found at: http://slntools.codeplex.com/

+6
source share

I never add files to Solution, only projects. If you need to add files, add them to the project.

If you do not want to merge, the alternative is that someone checks the solution with a new project, then pulls that project and solution down, overwriting your own solution file, and then re-adding your project to the solution and checking that back. Now the solution has both your project and yours.

+1
source share

I'm also very tired of the problem of merging with project files. (At some point, I was trying to resolve 9000+ conflicts in a single project file.)

So I did something with this: http://www.projectmerge.com

Although it started as a tool for comparing / combining project files, it quickly turned into something that could compare and merge any XML file.

I hope you find this helpful.

+1
source share

One suggestion to add to the comment pool ...

Work to minimize the changes you make to the SLN file when committing, to make it easier to merge others.

(Of course, the same goes for others).

To illustrate, suppose your SLN file currently displays four projects:

SLN: A, B, C, D

You and the employee have changed the changes. You add project E, plus (for some reason) things are reordering:

 Yours: A, E, D, C, B

Your peer changes include adding Project F:

 Co-Worker: A, B, C, D, F

If you make your changes as is, then your employee should be faced with a combination of these two:

 SLN: A, E, D, C, B Co-Worker: A, B, C, D, F

Nastya.

Instead, if you (carefully!) Work to minimize your differences, you can make your working copy as follows:

 Yours: A, B, C, D, E

In this case, when your colleague needs to unite, they will have to face this:

 SLN: A, B, C, D, E Co-Worker: A, B, C, D, F

Much easier to drain.

0
source share

More articles:


All Articles