Fusionando files vcproj – El infierno de SCM

La fusión de proyectos / files de solución es un desastre bien conocido entre los desarrolladores / administradores de SCM que realizan fusiones en su control de origen.

Tomemos, por ejemplo, un escenario común: el desarrollo se realiza en un proyecto / solución en dos twigs diferentes. Cuando llega el momento de fusionarse nuevamente en una línea de desarrollo principal, existe un pequeño parecido entre los VCPROJ (y los SLN).

La razón es que Visual Studio puede cambiar (y SÍ cambia) la location de los diversos elementos similares a XML dentro de estos files. Por ejemplo, Configurations Debug and Release puede cambiar el order en cada operación de guardado en el file proj. Esto hace que sea imposible incorporar cambios fácilmente desde cada twig de desarrollo, ni siquiera considerando una fusión automática.

Puedo suponer que Microsoft está usando algún sistema de hash de Perl para contener las estructuras de vcproj, por lo tanto, no se ordera el procesamiento de los files en una operación de salvar.

Primero me gustaría preguntar: ¿alguien encontró algún método elegante para resolver esto?

En segundo lugar, me gustaría hacer dos sugerencias:

  • Solicite a Microsoft que vuelva a implementar los files anteriores y que los restrinja a un order rígido de elementos.

  • encuentre una herramienta (o escriba una) que clasifique los files vcproj (formatting xml) y sln (formatting sln …) de forma alfabética, recursiva (todos los elementos dentro de los elementos, etc.). El uso de esta herramienta tanto en los files de origen como de destino permitiría apuntar (y fusionar) fácilmente los cambios, esperando que Visual Studio lea el proyecto combinado o el file sln.

Cualquier otra idea y pensamiento son bienvenidos.

Creé una herramienta para comparar y fusionar el file de solución ( http://slntools.codeplex.com ). Es mucho más fácil fusionar una solución con la herramienta en comparación con una 'fusión genérica'. No puede manejar los files del proyecto pensados.

Proyecto: Merge es mi herramienta para comparar y fusionar files XML. Originalmente lo escribí porque estaba experimentando exactamente este problema con los files de proyecto de Visual Studio.

Detecta correctamente los elementos y / o attributes reorderados dentro del file XML y resolverá correctamente casi todos los 'conflictos' automáticamente.

Es posible que desee considerar asociar su herramienta con un desencadenador dentro de su SCM (como un enlace de reenganche para SVN), para hacer cumplir el reorderamiento dentro de esos files.

Entonces tendrías la oportunidad de fusionar de manera eficiente estos elementos.

Por lo general, trato de evitar poner files generados automáticamente en SCM. Los files generados automáticamente deben generarse a partir de los files fuente que controla un desarrollador, y pueden colocarse en SCM. Si una herramienta en particular almacena datos en un formatting opaco y frágil, este es el problema de la herramienta.

En cuanto a Visual Studio, aunque creo que tiene comstackdores decentes, bibliotecas y un entorno de debugging, creo que los files en genera (PRJ, SLN, RC) son muy problemáticos. Además de los problemas que mencionas, también cambian mucho entre diferentes versiones VS. Por esta razón, escribimos nuestros propios files makefiles y construimos los progtwigs externamente, utilizando make. Además, dividimos los files de resources en partes para las cuales estamos obligados a confiar en VS, y aquellos que podemos manejar de forma sana con un editor normal. Generamos muchos files de resources automáticamente a partir de la descripción de alto nivel, escritos en lenguajes específicos de dominio personalizado. Por lo tanto, minimizamos el impacto de los cambios que son difíciles de manejar bajo SCM.

Lo que hacemos con los files de resources (no demasiados problemas con los files de proyecto) es orderarlos antes de la fusión. Hemos configurado el command de combinación en Plastic para ejecutar realmente un género (una aplicación diferente que hemos desarrollado para eso, podemos compartir el código si está interesado, nada especial) antes de fusionar, de modo que todas las reubicaciones aleatorias desaparecen. .. Espero eso ayude.

Verifique las opciones de installation: asegúrese de que todos sus colegas tengan instalado el componente de compilation x64 (o no todos)

He escrito una pequeña secuencia de commands Perl para fusionar files de solución:
http://blog.tedd.no/index.php/2011/01/06/merging-multiple-visual-studio-solution-sln-files-into-one/

La secuencia de commands se puede modificar para adaptarse a sus necesidades.

Hay un proyecto de google llamado gyp que genera soluciones y proyectos de Visual Studio de forma similar a CMake. Parte de ese proyecto son las herramientas de Python para orderar los nodos xml y los attributes de los files .sln y .vcproj, respectivamente: pretty_sln y pretty_vcproj. Puede downloadlos de forma independiente desde http://gyp.googlecode.com/svn/trunk/tools/

Solo miré a pretty_vcproj hasta ahora, también expande files .vsprop importados en vcproj, probablemente para comparar el contenido exacto de dos vcprojs. El vcproj resultante no se ajusta al esquema proporcionado por Microsoft, pero probablemente funcionaría bien, o uno podría cambiarlo para clasificar únicamente los nodos de "Configuración" y "Plataforma", dejando todo lo demás intacto. No estoy seguro si vale la pena el esfuerzo, ya que parece haber otros proyectos dirigidos a normalizar vcprojs ya …