VS2010 .filter files and SVN

Question

Since we've switched to VS2010 we've noticed a new .filters file that apparently contains the filter structure of the project. We're also using subversion as our source control.

Unfortunately, every time we check in now we end up with merge conflicts if anyone's added a file or filter to the project. SVN seems absolutely incapable of merging this file type correctly even though it's text based. It's getting rather frustrating.

Is anyone else dealing with this problem? Has anyone found a solution?

Example conflict, coder 'a' adds whatever.txt and checks in, coder 'b' adds filter and new .cpp file and updates. Gets this:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ItemGroup>
    <Filter Include="filter_1">
      <UniqueIdentifier>{065f6d5d-81b2-4c98-b313-dceb16c24bf2}</UniqueIdentifier>
    </Filter>
    <Filter Include="filter_2">
      <UniqueIdentifier>{85ef5151-d045-4b20-b1bf-e65d380a3cf3}</UniqueIdentifier>
    </Filter>
    <Filter Include="filter_2\sub_filter_1">
      <UniqueIdentifier>{90efdbe3-b53a-41fc-9dfb-147df5e7d7f3}</UniqueIdentifier>
    </Filter>
    <Filter Include="NewFilter1">
      <UniqueIdentifier>{8162b584-12a0-4a05-8cc5-ede4ced07ba3}</UniqueIdentifier>
    </Filter>
  </ItemGroup>
  <ItemGroup>
    <ClInclude Include="filter_2\file_3.hpp">
      <Filter>filter_2</Filter>
    </ClInclude>
    <ClInclude Include="filter_2\sub_filter_1\file_4.hpp">
      <Filter>filter_2\sub_filter_1</Filter>
    </ClInclude>
    <ClInclude Include="filter_1\file_1.hpp">
      <Filter>filter_1</Filter>
    </ClInclude>
    <ClInclude Include="filter_1\file_2.hpp">
      <Filter>filter_1</Filter>
    </ClInclude>
  </ItemGroup>
<<<<<<< .mine
  <ItemGroup>
    <ClCompile Include="whatnot.cpp">
      <Filter>NewFilter1</Filter>
    </ClCompile>
  </ItemGroup>
=======
  <ItemGroup>
    <None Include="whatever.txt" />
  </ItemGroup>
>>>>>>> .r12513
</Project>

Answer 1

We're experiencing this same problem. It's nothing to do with them not being merged correctly due to text/binary status, but rather because of a quirk of the SVN merging.

Typically if one person adds a new file to the project and commits then the diff will be something like:

   <ClCompile Include="dir1\newfile1">
      <Filter>dir1</Filter>
    </ClCompile>

Meanwhile, user2 adds a new file to the same filter (ie the folder node in the solution tree):

   <ClCompile Include="dir1\newfile2">
      <Filter>dir1</Filter>
    </ClCompile>

When user2 updates they'll get a conflict

   <<<<<
   <ClCompile Include="dir1\newfile1">
   =====
   <ClCompile Include="dir1\newfile2">
   >>>>>>
      <Filter>dir1</Filter>
    </ClCompile>

The crucial thing is how you resolve the conflict. If you use the 'Use A then B' option of your merge tool then you'll end up with this:

   <ClCompile Include="dir1\newfile1">
   <ClCompile Include="dir1\newfile2">
      <Filter>dir1</Filter>
    </ClCompile>

which is invalid XML. Unfortunately VisualStudio doesn't always seem to complain about this (though it usually does -- seems to depend on the precise nature of the change). So you can then end up with some files orphaned from their filters -- I think in this case it'll try to fix it by finishing the first <CLCompile>:

   <ClCompile Include="dir1\newfile1" />

This then means that newfile1 will appear at the top level of the project rather than in the dir1 filter. Once you have some invalid nodes appearing it seems that you'll start to get more conflicts until someone fixes up the project.

So, the solution to all this is that you need to make users aware of the structure of the file when they resolve conflicts, don't just blindly rely on the merge tool. You have to ensure that every entry has all 3 lines: the opening <CLCompile> or <CLInclude>, the filter, and the end tag.

This whole problem only really exists because of a quirk of the xml in that a conflict will only affect one or two of the three lines. If the XML end tag was on the same line as the filter then it wouldn't happen.

Answer 2

They're plain xml files like the visual studio other project files - I can't see why they should be any more susceptible to conflicts than other project files.

Are these files perchance being treated as binary and not as text? Merging binary files won't work - check the svn properties to see what mime-type they're set to (if no mime-type is set, you should be fine). If the mime type is set, it's possible you're dealing with a misconfigured automatic property.

Finally, it's possible people are constantly adding+removing files - if so, you may just need to commit and update more frequently until the project settles down a bit more.

You definitely should not svn:ignore these files.