Merging vcproj files - SCM's hell

Question

Hi all,

Merging project/solution files is a well-known disaster among developers/SCM admins performing merges in their source control.

Take, for example, a common scenario: development is done on a project/solution in two different branches. When time comes to merge back into a main development line, there is a very small resemblence between the VCPROJ's (and SLNs).

The reason is, Visual Studio may change (and DOES change) location of the various XML-like elements within these files. E.g., Configurations Debug and Release may swap order upon every save operation on the proj file. This makes it impossible to easily incorporate changes from each development branch, not even considering an automatic merge.

I can assume that Microsoft are using some perl hashing system to hold the vcproj structures, hence the rendering of the files upon a save operation is not ordered.

I'd first like to ask: did anyone found some elegant method to workaround this?

Second, I'd like to make two suggestions:

• Have Microsoft please reimplement the above files and restrict them to some rigid ordering of elements.

• find a tool (or write one) that sorts vcproj (xml format) and sln (sln format...) files alphabetically, recursively (all elements within elements etc.). Using this tool on both source and target files would enable to easily point (and merge) the changes, hoping that Visual Studio reads the sorted, merged project or sln file.

Any other ideas and thoughts are welcome.

Gil Moses.

Answer 1

You might want to consider associating your tool with a trigger within your SCM (like a re-commit hook for SVN), in order to enforce the re-ordering within those files.

Then you would stand a chance to efficiently merging these elements together.

Answer 2

I typically try to avoid putting automatically-generated files under SCM. Automatically-generated files should be generated from source files that a developer controls, and those can be put under SCM. If a particular tool stores data in an opaque and fragile format, this is the tool's problem.

Regarding Visual Studio, although I think it has decent compilers, libraries, and a debugging environment, I believe that the files in generates (PRJ, SLN, RC) are highly problematic. Apart from the problems you mention, they also change a lot between different VS versions. For this reason, we write our own makefiles, and build the programs externally, using make. Furthermore, we split the resource files into parts for which we are forced to rely on VS, and those we can sanely handle with a normal editor. We generate many resource files automatically from high-level description, written in custom domain-specific languages. We thus minimize the impact of changes that are difficult to handle under SCM.

Answer 3

This doesn't seem to offer any great help either:

http://social.msdn.microsoft.com/Forums/en-US/tfsversioncontrol/thread/4dfcf6df-c80f-49aa-acbc-660558e4556b/

it actually adds a +1 for makefiles unfortunately.

I have not yet run into this problem because of the nature of the projects I work on. (smaller teams and minimal if any branching of project files) I am amazed at Microsoft's appalling shortcoming here; what a huge mistake.

Answer 4

I created a tool to compare and merge solution file (http://slntools.codeplex.com). It's a lot easier to merge a solution with the tool compared to a 'generic merger'. It cannot handle project files thought.

Answer 5

What we do with resource files (not so much trouble with project files) is to sort them prior merging. We've configured the merge command on Plastic to actually run a sort (a different app we've developed for that, we can share the code if you're interested, nothing fancy) before merging, so all the random relocations go away... Hope it helps.

Answer 6

Project: Merge is my tool for comparing and merging XML files. I originally wrote it because I was experiencing exactly this problem with Visual Studio project files.

It correctly detects re-ordered elements and/or attributes within the XML file and will correctly resolve nearly all 'conflicts' automatically.