How to deal with merging of Visual Studio projects

Question

Visual studio projects, as opposed to makefiles or other projects I know, have some quirks:

• The directory structure of the project has no real connection to actual directory structure - all directories are purely virtual - this makes it harder to re-add mass of files while keeping directory structure
• The project consists of rather complex XML, that file contains everything from files to compiler settings

Now whenever I merge branches, I have conflict on the project files, because everyone inadvertently changes them as they operate over the project. Often the changes happen in such ways that the merge tool does not even recognize conflict properly. In those cases, files end up missing in the project, outdated settings reappear and so on.

Our project is 2010 C++ solution consisting of five separate sub-projects.

Are there any strategies that would have low impact on the development process, but would alleviate problems caused by merging project files?

Answer 1

I find there are a couple things you can do to virtually eliminate this problem.

1. More projects. Spreading code changes over more projects means less chance of a merge conflict and simpler projects files when you do get them.

2. Build all your branches on the build server. This picks up build failures due to people forgetting to save the project when they add a file. Before they merge in their branch.

3. Make everyone use the same version of visual studio

4. Make sure as many settings as possible go in the .csproj.user file rather than .csproj and exclude this from source control.

Answer 2

This is a classic case for continuous integration where everybody checks into 1 branch.

1. Developers should be able to resolve basic conflicts correctly, I'm assuming your conflicts are great in scope to cause what you describe.

2. When checking into the same branch while working on the same proj file, with everybody checking in at least once a day, the conflicts will still occur, but 1-2 at a time typically and that will make them manageable.

You should also apply Ewan's suggestions on top of this.

Answer 3

Writing your own merge tool may be a feasible solution. Git integration is fairly straight forward, https://www.git-scm.com/docs/git-mergetool#_options:

• Set tool path and arguments
• Tool locate files to merge and result file by environment variables
• Tool decides for merge success or failure (your preference)

If writing your own tool you can make decisions based on whether elements are order dependent or independent (similar to .gitattributes merge=union, but only when sensible), perhaps deduce rename operations, break down line changes into smaller components. Sky is the limit.

And should you make it a successful open source project, you will become legend.