8

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?

  • "in such ways that the merge tool does not even recognize conflict properly" - never encountered such a situation by myself Which programming languages and project types are you using mainly? – Doc Brown Jan 18 '17 at 19:17
  • How does project language affect what does meerge tool to XML files? The problem is that certain changes are automatically resolve and not marked as conflict. – Tomáš Zato - Reinstate Monica Jan 18 '17 at 19:51
  • C++ project files are somewhat different from other .NET language files, in general more complex. – Doc Brown Jan 18 '17 at 20:18
  • 1
    Found this article by a quick google search: haacked.com/archive/2014/04/16/csproj-merge-conflicts Do you have a configuration like *.csproj merge=union in your .gitattributes? – Doc Brown Jan 18 '17 at 20:25
  • @DocBrown No I don't. But I read the article and maybe enforcing conflicts on those files is what I need. I wonder if I could enforce behavior they describe on any file type I chose. – Tomáš Zato - Reinstate Monica Jan 24 '17 at 11:28
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.

| improve this answer | |
0

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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.