¿Cómo se gestionan los archivos .vcproj en el control de origen que cambian varios desarrolladores?

Question

Usamos Subversion como nuestro sistema de control de código fuente y almacenamos los archivos del proyecto VisualStudio (vcproj) en el sistema de control de código fuente, como es normal, creo. Con Subversion no utilizamos ningún tipo de bloqueo de archivos, por lo tanto, si dos desarrolladores trabajan en el mismo proyecto al mismo tiempo y ambos agregan archivos al proyecto o cambian la configuración, el segundo que se comprometa debe combinar los cambios.

¿Cómo fusionar estos cambios?

Los archivos vcproj son solo archivos de texto, por lo que es posible editarlos a mano, pero no son muy adecuados para la edición manual, especialmente por desarrolladores junior.

Las formas en que puedo pensar son

• Obtenga la última versión de svn y vuelva a agregar todos los cambios locales manualmente
• Edite el archivo a mano para resolver cualquier conflicto de una fusión automática
• Implemente alguna forma de esquema de bloqueo para evitar cambios simultáneos
• Tener un acuerdo entre los desarrolladores para que no realicen cambios simultáneos

Actualmente estamos usando la primera opción de volver a agregar todos los cambios manualmente, pero esto lleva mucho tiempo y me preguntaba si hay una mejor manera.

Con los archivos fuente, la función de fusión automática funciona la mayor parte del tiempo y no tenemos muchos conflictos.

Answer 1

He encontrado que la opción 2 (editar los archivos a mano) generalmente funciona bastante bien, siempre y cuando estés usando una buena herramienta de diferencias (yo uso WinMerge ). El principal problema con el que me he encontrado es que Visual Studio a veces reordena el archivo. Pero, si tiene una buena herramienta de diferencias / fusión, entonces debería poder diferenciar entre el contenido modificado y el contenido movido. Eso puede ayudar mucho.

Answer 2

Puede encontrar Project: Merge o Herramientas para archivo SLN útil

Answer 3

Este es un problema difícil y creo que es una debilidad en la arquitectura de Visual Studio. La forma en que lo encontramos fue no tener los archivos de proyecto en el control de origen y tener un script de compilación que controlara los ajustes de configuración.

La alternativa era muy desordenada y no podíamos garantizar compilaciones o entornos consistentes entre desarrolladores. Esto dio lugar a una gran cantidad de problemas de integración descendente y, finalmente, tomamos el paso draconiano de eliminar los archivos del proyecto del control de código fuente.

Los entornos de los desarrolladores aún podrían desalinearse, pero aparecieron cuando intentaron construir cosas por sí mismos.

Answer 4

Usando TFS aquí, pero no creo que haga la diferencia.
Tampoco bloqueamos, y a veces tenemos que lidiar con la fusión de archivos de proyecto. Nunca he encontrado que sea tan complejo o un gran problema. Rara vez experimentamos problemas que no se pueden combinar automáticamente, y el proceso de combinación manual es bastante trivial.

Solo hay una advertencia para esto: ¡Regístrese a menudo! Si realiza cambios importantes en la estructura del proyecto y no los verifica inmediatamente, esos cambios pueden comenzar a complicar la complejidad de las fusiones posteriores. Si hago un cambio importante en la estructura de un proyecto, generalmente les aviso a todos. Les pediré a todos que verifiquen su trabajo actual y luego me encargue de la fusión.

Answer 5

Encontré esto recientemente: http://www.codeproject.com/KB/macros /vcproj_formatter.aspx Si ejecuta esta herramienta en un archivo vcproj y en una versión modificada, puede combinarlos fácilmente con su herramienta de combinación de texto favorita, y además el resultado es un archivo vcproj bastante más compacto.

Answer 6

Las opciones 1 y 2 no son mutuamente excluyentes: si el desarrollador es de nivel junior, permítales usar la opción 1 (volver a obtener el archivo del proyecto y volver a hacer los cambios) si eso es más cómodo para ellos. Para desarrolladores más avanzados, la opción 2 (fusionar usando una herramienta de fusión) está perfectamente bien.

Creo que esta es una situación que actualmente no tiene una bala mágica, a veces fusionarse es un dolor.

Answer 7

Utilizamos una herramienta diff ( WinMerge ) para fusionar los cambios. Los archivos del proyecto son (en su mayor parte) XML realmente sencillo. Sin embargo, la clave aquí es que nunca debe haber sorpresas al fusionarse, porque una buena comunicación es parte de la roca de la cama para el control efectivo de la fuente.

Los cambios simultáneos al proyecto están perfectamente bien siempre que las personas se comuniquen.