How do you manage .vcproj files in souce control which are changed by multiple developers?

Question

We use Subversion as our source control system and store the VisualStudio project files (vcproj) in the source control system as is normal I think. With Subversion we don't use any form of file locking, so if two developers are working on the same project at the same time and both add files to the project, or change settings, the second one to commit has to merge the changes.

How do you merge these changes?

The vcproj files are just text files so it is possible to edit them by hand but they are not very amenable to hand editing, especially by junior developers.

The ways I can think of are

• Get the latest version from svn and re-add all local changes manually
• Edit the file by hand to resolve any conflicts from an automatic merge
• Implement some form of locking scheme to prevent simultaneous changes
• Have an agreement between developers so they do not make simultaneous changes

Currently we are using the first option of re-adding all changes manually but this is time consuming and I was wondering if there is a better way.

With source files the automatic merge feature works most of the time and we don't get many conflicts.

Answer 1

I've found that option 2 (edit the files by hand) generally works fairly well, as long as you're using a good diff tool (I use WinMerge). The main problem I've run into is that Visual Studio will sometimes reorder the file. But, if you have a good diff/merge tool then it should be able to differentiate between changed content and moved content. That can help a lot.

Answer 2

We use a diff tool (WinMerge) to merge changes. The project files are (for the most part) really straight-forward XML. The key here, though, is that there never should be any surprises when merging, because good communication is part of the bed-rock of effective source control.

Simultaneous changes to the project are perfectly fine as long as people communicate.

Answer 3

This is a tough problem and I think a weakness in the Visual Studio architecture. The way we found round it was to not have the proj files in source control at all and to have a build script that handled the configuration settings.

The alternative was very messy and we could not guarantee consistent builds or environments between developers. This led to a huge number of downstream integration problems and eventually we took the draconian step of removing the project files from source control.

The developers environments could still become misaligned but it showed up when they tried to build things themselves.

Answer 4

Using TFS here, but I don't think it makes a difference.
We also don't lock, and sometimes have to deal with merging project files. I've never found it to be that complex or much of an issue. Rarely do we ever experience issues that can't be merged automatically, and the manual merge process is pretty much trivial.

There's only one caveat to this: Check in often! If you make major changes to the project structure and don't check them in immediately those changes can start compounding the complexity of later merges. If I make a major change to the structure of a project, I usually give everybody a heads up. I'll ask them all to check in their current work, and then take care of the merge myself.

Answer 5

Options 1 and 2 are not mutually exclusive - if the developer is junior level, let them use option 1 (re-get the project file and re-do the changes) if that's more comfortable for them. For more senior developers, option 2 (merge using a merge tool) is perfectly fine.

I think this is a situation that currently has no magic bullet - sometimes merging is a pain.

Answer 6

You might find Project: Merge or Tools for SLN file useful