ansaurus

Question

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

Answer 1

+13 A:

My suggestion would be to update and commit more frequently. In particular, make sure you run Get Latest before pending any changes on a solution file.

"Merge hell" with things like XML and text files (which all project and solution files are) typically only occurs because people are trying to commit single changes that are very large.

If you get into the habit of doing regular commits, the merges tend to be smaller, and the tools tend to do a perfect job of it.

Reed Copsey 2010-03-16 16:52:00

I would also suggest that you get your people comfortable with stopping and askign questions if they aren't sure how to merge a solution file. I worked at a place where several times a week I would have to manually clean the solution file because people would automerge instead of checking the results. (And the SLN is not XML.)

Matthew Whited 2010-03-16 17:00:20

@Reed, I must disagree. Have you actually run an automerge tool against a *.sln file where two people have added new projects? There is literally no way it will succeed due to the way projects are assigned numbers.

Richard Berg 2010-03-17 00:00:36

@Richard: If you update and commit frequently, this should never happen. Personally, I make my team always update prior to a commit. I personally feel that a new project being added should be a commit all of it's own. This means you update, commit any changes. Then add your project, and commit that. Basically, you should NEVER have two "new" projects to merge, unless two people try to add a new project within the same few minute timeframe (very unlikely)...

Reed Copsey 2010-03-17 00:04:37

@Richard: If you're trying to merge a single project being added to the .sln, it works fine. I do this all the time...

Reed Copsey 2010-03-17 00:05:00

Richard Berg 2010-03-17 00:50:06

@Richard: Did you read my entire comment? I agree that this can be a problem, but if you're committed regularly, it only happens if two people try to add a project in the same commit window. I personally think adding a project should be its own commit, so that window should be like a 5 minute window - very unlikely two people need to add a new project in the same few minutes...

Reed Copsey 2010-03-17 00:52:49

@Reed: I take it your developers have some sort of background process/trigger that runs Get Latest every 5 minutes? Yes, that would limit the problem to a 5min window at worst. But I don't think that methodology is very common (nor would it be practical on large servers).

Richard Berg 2010-03-17 02:39:14

@Richard You don't need to get latest every 5 minutes. The dev that is adding the project first updates(ensuring he has the latest version of sln along with any project adds other devs have done), adds his project to the solution, and then commits. This is the 5 minute window he is referring to. There is only an issue if two devs add a project independently within that 5 minute window, and even then it is as simple as doing an update again, re-adding my project and committing.

AaronLS 2010-03-17 14:56:42

Ok, so the constraint is "always run Get before pending any changes on the solution." Fair enough.

Richard Berg 2010-03-17 20:48:08

Added this specific advice to Reed's answer so that I could change my vote.

Richard Berg 2010-03-17 20:54:03

@Richard: That, and "always commit immediately after changing the solution". Between the two things, my current team has never had a single problem that required hand-editing the solution file. Prior to doing that, it was a constant nightmare...

Reed Copsey 2010-03-17 20:58:07

@Richard: Thanks ;)

Reed Copsey 2010-03-17 21:01:24

Answer 2

+1 A:

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

If you don't want to merge, then the alternative is if someone checks in a solution with a new project, then pull that project and the solution down, overwriting your own solution file, then re-add your project to the solution and check that back in. Now the solution has both their project and yours.

AaronLS 2010-03-16 16:54:16

Some files are nice to have one the solution as a reference. Examples I have used in the past would be third party assemblies, strong naming keys, general notes, and shared config files.

Matthew Whited 2010-03-16 16:56:53

I place these in an empty project. The problem is the "virtual" folders used by solutions can cause you to have inconsistencies between machines. When you check out the solution and files on a different machine, they may not be in the same relative directory structure that they were for the developer who added the files. Solutions also allow references to files like "..\..\OutsideFolder" which can create havoc when another developer attempts to pull the solution from source control.

AaronLS 2010-03-16 18:57:14

I agree with aaronis that you need to be careful with relative paths. However, it is pretty normal to add third party assemblies to the solution as Matthew explains. What I always do is create a directory named 'Shared Assemblies' for the 3rd party dlls in the solution directory and create a solution folder with that same name. This way I never have any of the problems aaronis describes.

Steven 2010-03-16 21:04:01

@aaronls that's exactly what I'm doing already, but I was hoping there was a better way :)

2010-03-17 07:55:41

Answer 3

A:

One suggestion to add to the pool of comments ...

Work on minimizing the changes you make to the SLN file when you commit, to make it easier for others to merge.

(Of course, the same goes for the others as well).

To illustrate, assume your SLN file currently lists four projects:

SLN: A, B, C, D

You and a co-worker both make changes. You add project E, plus (for some reason) things get reordered:

Yours:  A, E, D, C, B

Your co-workers changes involve adding project F:

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

If you commit your changes as is, then your co-worker has to face merging these two:

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

Nasty.

Instead, if you (carefully!) work to minimise your differences, you can make your working copy look like this:

Yours:  A, B, C, D, E

In this case, when your co-worker needs to merge, they'll have to face this:

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

Much easier to merge.

Bevan 2010-03-17 21:01:02

Answer 4

A:

I too was very fed up with merge problems with project files. (At one point I was trying to resolve 9000+ conflicts in a single project file.)

So I did something about it: http://www.projectmerge.com

Although this started out as a project file compare/merge tool, it quickly evolved into something that can compare and merge any XML file.

Hope you find it useful.

James 2010-08-14 15:03:03

Answer 5

A:

I made a tool to specifically to compare / merge solution file (and can also be used to dynamically create filtered solution as well).

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

Christian Warren 2010-09-02 17:27:53

ansaurus

tags:

views:

answers:

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

related questions