VS2010.filter and SVN files

Question

Since we switched to VS2010, we noticed a new .filters file, which, apparently, contains the project filter structure. We also use subversion as a source of control.

Unfortunately, every time we register, we end up with merge conflicts if someone added a file or filter to the project. SVN seems completely unable to correctly change this type of file, even if it is text based. This is getting rather unpleasant.

Does anyone else deal with this issue? Has anyone found a solution?

An example of a conflict, coder 'a' adds what.txt and checks if coder 'b' adds a filter and a new .cpp file and updates. Gets the following:

<?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

They are simple XML files, such as other visual studio project files. I do not understand why they should be more susceptible to conflicts than other project files.

Are these perchance files processed as binary and not as text? Merging binary files will not work - check the svn properties to find out what type of mime type they are installed (if the mime type is not set, you should be fine). If the mime type is specified, you are probably dealing with a misconfigured automatic property .

Finally, it is possible that people are constantly adding + deleting files - if so, you may only need to commit and update more often until the project installs a little more.

You definitely should not svn:ignore these files.

Answer 2

We have the same problem. This is not due to the fact that they do not merge correctly due to text / binary status, but rather because of the fad of SVN merging.

Usually, if one person adds a new project to the project and commits, then the diff will look something like this:

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

Meanwhile, user2 adds a new file to the same filter (that is, the node folder in the decision tree):

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

When updating user2 they will get a conflict

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

Most importantly, how do you resolve the conflict. If you use the "Use A Then B" option of your merge tool, you will get the following:

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

which is invalid xml. Unfortunately, VisualStudio does not always complain about this (although usually it does, it seems to depend on the exact nature of the changes). This way you can get some files lost from your filters - I think in this case he will try to fix this by ending the first <CLCompile> :

  <ClCompile Include="dir1\newfile1" /> 

This means that newfile1 will appear at the top level of the project, and not in the dir1 filter. Once you have some invalid nodes, it seems that you will begin to get more conflicts until someone fixes the project.

So, the solution to all this is that you need to inform users about the file structure when resolving conflicts, and not just blindly rely on the merge tool. You must make sure that each entry has all three lines: opening <CLCompile> or <CLInclude> , filter and end tag.

This whole problem exists only because of the quirk of xml, as the conflict affects only one or two of the three lines. If the final XML tag is on the same line as the filter, this will not happen.

Answer 3

If the .filters file is something specific to user configuration, then it probably doesn’t apply to Subversion at all. You can force Subversion to ignore changes to the file using the svn: ignore property:

  svn propset svn: ignore '.filters'.

The above command will cause Subversion to start ignoring changes to the file named ".filters".

Another option is to force Subversion to process the .filters file as a binary:

  svn propset svn: mime-type 'application / octet-stream' .filters

The above command will force the .filters file to be treated as a binary file and will not be merged.

Edit
Now that you have explained that the ".filters" file is necessary for the project, and also that the problem may be that it is considered as binary rather than plain text, the solution is to set the type to plain text:

 svn propset svn:mime-type 'text/plain' .filters 

Answer 4

I suggest this with regard to the .vcxproj.filters file:

When I create a C ++ project with Visual Studio 2010, Version 10.0.40219.1 SP1Rel, it generates a file called ReadMe.txt in the project folder, which includes this text:

 <YourProjectName>.vcxproj.filters This is the filters file for VC++ projects generated using an Application Wizard. It contains information about the association between the files in your project and the filters. This association is used in the IDE to show grouping of files with similar extensions under a specific node (for eg ".cpp" files are associated with the "Source Files" filter). 

So this confirms that the .vcxproj.filters file defines the folder structure that you see in Solution Explorer.