VS2010 .filter files and SVN

Question

Desde que cambiamos a VS2010, notamos un nuevo archivo .filters que aparentemente contiene la estructura de filtro del proyecto. También usamos subversion como nuestro control de fuente.

Desafortunadamente, cada vez que nos registramos ahora terminamos con conflictos de combinación si alguien ha agregado un archivo o filtro al proyecto. SVN parece absolutamente incapaz de combinar este tipo de archivo correctamente aunque esté basado en texto. Se está volviendo bastante frustrante.

¿Alguien más está lidiando con este problema? ¿Ha encontrado alguien una solución?

Ejemplo de conflicto, el codificador 'a' agrega whatever.txt y lo registra, el codificador 'b' agrega el filtro y el nuevo archivo .cpp y las actualizaciones. Obtiene la siguiente:

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

Son archivos xml lisos como los otros archivos de proyecto de visual studio - no puedo ver por qué deberían ser cualquier más susceptibles a los conflictos que otros archivos de proyecto.

¿Estos archivos quizás se tratan como binarios y no como texto? La fusión de archivos binarios no funcionará - verifique las propiedades de svn para ver qué tipo de mime están configurados (si no está configurado el tipo mime, debería estar bien). Si está configurado el tipo MIME, es posible que esté lidiando con un automatic property mal configurado.

Finalmente, es posible que las personas agreguen o eliminen archivos constantemente; de ​​ser así, puede que solo deba confirmar y actualizar con más frecuencia hasta que el proyecto se establezca un poco más.

Definitivamente no debe svn:ignore estos archivos.

Answer 2

Si el archivo ".filters" es algo específico de la configuración del usuario, entonces probablemente no pertenece a la subversión en absoluto. Puede hacer caso omiso de la subversión cambios en el archivo utilizando la propiedad svn: ignore:

 
svn propset svn:ignore '.filters' . 

El comando anterior hará que la subversión comience a ignorar los cambios en el archivo llamado ".filters".

Otra opción es forzar subversión para tratar el archivo ".filters" como un archivo binario:

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

El comando anterior hará que el archivo ".filters" a ser tratado como un archivo binario y de la voluntad no ser fusionado

Editar
Ahora que ha explicado que el archivo ".filters" es esencial para el proyecto y también que el problema puede ser que está siendo tratado como binario en lugar de como texto sin formato, la solución es para establecer el tipo de texto llano:

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

Answer 3

voy a ofrecer este respecto a la finalidad del fichero .vcxproj.filters:

Cuando creo un proyecto de C++ con Visual Studio 2010, versión 10.0.40219.1 SP1Rel, se genera un archivo llamado ReadMe.txt en la carpeta de proyectos que incluye este texto:

<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 e.g. ".cpp" files are associated with the 
    "Source Files" filter). 

Así que, de hecho, esto confirma que el archivo .vcxproj.filters gobierna la estructura de carpetas que se ve en el Explorador de soluciones.

Answer 4

Estamos experimentando el mismo problema. No tiene nada que ver con que no se combinen correctamente debido al texto/estado binario, sino más bien a causa de una peculiaridad de la fusión de SVN.

Normalmente, si una persona agrega un nuevo archivo al proyecto y se compromete entonces la comparación será algo como:

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

Mientras tanto, usuario2 añade un nuevo archivo en el mismo filtro (es decir, el nodo de carpeta en el árbol de soluciones):

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

Cuando las actualizaciones Usuario2 que obtendrá un conflicto

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

Lo crucial es cómo resolver el conflicto. Si se utiliza el 'uso A entonces B' opción de la herramienta de combinación, entonces va a terminar con esto:

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

que es XML válido. Lamentablemente, VisualStudio no siempre se queja de esto (aunque generalmente lo hace, parece depender de la naturaleza precisa del cambio). Por lo que puede terminar con algunos archivos huérfanos de sus filtros - Creo que en este caso se va a tratar de arreglarlo al terminar la primera <CLCompile>:

<ClCompile Include="dir1\newfile1" /> 

Esto significa, entonces, que newfile1 aparecerá en la parte superior nivel del proyecto en lugar de en el filtro dir1. Una vez que aparecen algunos nodos inválidos, parece que comenzará a tener más conflictos hasta que alguien solucione el problema.

Por lo tanto, la solución a todo esto es que necesita hacer que los usuarios conozcan la estructura del archivo cuando resuelven conflictos, no simplemente confíe ciegamente en la herramienta de fusión. Debe asegurarse de que cada entrada tenga las 3 líneas: la apertura <CLCompile> o <CLInclude>, el filtro y la etiqueta final.

Todo este problema solo existe debido a una peculiaridad del xml en que un conflicto solo afectará a una o dos de las tres líneas. Si la etiqueta final XML estaba en la misma línea que el filtro, entonces no sucedería.