Sugerencias para mantener los files del proyecto vcproj de Visual Studio en el control de versiones

Microsoft Visual Studio usa XML para save sus files de proyecto .vcproj . Entonces, los files de proyectos XML diferentes deberían ser fáciles.

Desafortunadamente, si cambia alguna de las properties del file de proyecto, Visual Studio insiste en mezclar aleatoriamente los nodos XML del file de proyecto. Esto hace que la diferencia textual y la fusión de los cambios en el file del proyecto sean básicamente imposibles. ¡Cambiar la configuration de un comstackdor puede hacer que mi herramienta visual diff piense que he cambiado el 50% de las líneas en el file! Incluso he probado algunas herramientas XML diff, pero solo muestran una vista más estructurada del mismo desastre.

¿Alguien tiene alguna sugerencia para mantener los files .vcproj en control de fuente? ¿O una forma de convencer a Visual Studio para que no reorganice los nodos XML en el file .vcproj ?

(También he investigado el uso de herramientas como CMake para generar files .vcproj desde un file de text más fácil de usar, pero CMake tiene sus propios problemas).

Esto parece popup de vez en cuando.

  • Fusionando files vcproj – El infierno de SCM

Tal vez es un problema maduro para un plug-in u otra herramienta de normalización.

Sería un gran negocio secundario, hasta que MS decida arreglarlo. Entonces no tiene suerte, a less que ofrezcan comprar su IP.

¿Alguien quiere comenzar un proyecto de código abierto o un producto comercial? Estoy juego.

Podría probar una herramienta de normalización autónoma, luego ver si puedo convertirla en un complemento.

Estamos viendo esto aquí en el trabajo ahora, con files de proyectos donde las configuraciones se reorderan en computadoras de varias personas, y es muy frustrante …

* Nota: Todos usamos VS 2008 Pro, no equipo

Al principio parece que se reorderan aleatoriamente, pero de hecho hay un patrón y no es aleatorio en absoluto.

Para un grupo, las configuraciones están orderadas por Plataforma, luego por Configuración:

  • Depurar | Win32
  • Depurar | x64
  • Lanzamiento | Win32
  • Lanzamiento | x64
  • Depurar DX11 | Win32
  • Depurar DX11 | x64
  • Versión DX11 | Win32
  • Versión DX11 | x64

Para el otro grupo, las configuraciones son orderadas por Config, luego por Plataforma:

  • Depurar | Win32
  • Lanzamiento | Win32
  • Depurar DX11 | Win32
  • Versión DX11 | Win32
  • Depurar | x64
  • Lanzamiento | x64
  • Depurar DX11 | x64
  • Versión DX11 | x64

Mirando a través de la historia forzosa, esto es consistente con múltiples proyectos presentados por los mismos grupos de personas, y hay una split de 50/50, por lo que no solo le está sucediendo a una persona.

¿Es este el mismo problema que todos ustedes están viendo? Si es así, espero que este patrón ayude a encontrar una solución que no implique un paso macro / extra diff …

Tiene que ser un ajuste en algún lugar, o un efecto secundario de hacer clic en algo, ya que es 100% reproducible por cada una de estas máquinas. Incluso si es algo tonto, como la opción que elija para su layout de entorno inicial (VC ++, VB, Desarrollo general, etc.)

Utilizo WinMerge como mi herramienta diff y habilité la detección de bloques movidos. No soluciona el problema, pero hace que las diferencias sean un poco más soportables.

¿En qué versión de Visual Studio estás viendo esto?

Trabajo mucho con files .vcproj (mantenemos versiones de los files de proyecto para nuestras bibliotecas en múltiples versiones de Visual Studio, y siempre estoy difiriendo y fusionando las cosas) pero nunca he visto este comportamiento.

Mi equipo en Adobe ha visto lo mismo en el vs2008. Solo un proyecto básico de debugging / liberación, win32 / win64 le ofrece 4 configuraciones y mezcla aleatoria. Varias personas han intentado averiguar cuándo y por qué devstudio reordera, pero el pensamiento actual es que la key de sorting es un hash de palabras key, por lo tanto, semi-aleatorio. Nos hemos rendido y en las revisiones de los códigos solo resumimos los cambios "reales".

Creo que he encontrado el motivo de esta confusión. Al less en VS2008.

Si instala los comstackdores x64, VS orderará los proyectos como:

 Debug|Win32 Debug|x64 Release|Win32 Release|x64 

Si no lo hace, los orderará como:

 Debug|Win32 Release|Win32 Debug|x64 Release|x64 

Así que asegúrese de que todos sus pares tengan instalado el mismo comstackdor, por lo que no se mezclará.

Probado y este comportamiento parece ser reproducible.