Visual Studio, svn y fusión de archivos .csproj y .sln

Question

¿Alguien tuvo éxito al obtener SVN para fusionar los proyectos de Visual Studio (.csproj) o los archivos de solución (.sln) que han sido editados por dos usuarios? Ejemplo

1. usuario A desprotege proyecto
2. usuario B desprotege mismo proyecto
3. usuario A agrega un archivo
4. usuario A comete cambios
5. usuario B añade un archivo
6. usuario B se compromete cambios

Me parece que en el paso (6), svn, Tortoise, Ankh o lo que sea resuelve un conflicto y fusiona los dos archivos de proyecto automáticamente o, más probablemente, solicita al usuario B que resuelva el conflicto. Actualmente, estamos viendo los cambios realizados por el Usuario A borrados cuando el Usuario B ingresa, lo que da como resultado compilaciones incorrectas, implementaciones, etc., características que faltan que se agregaron antes de la última verificación.

Dado que los archivos del proyecto son XML, ¿por qué es esto un problema? ¿Me estoy perdiendo de algo? He buscado en los archivos aquí y he buscado en Google y ya no puedo buscar en Google, pero no he encontrado una buena solución.

Answer 1

¿Cómo crees que engañas a SVN para que realice el paso # 6? Parece que no entendiste lo que salió mal. SVN nunca se comprometerá con una copia de trabajo que no está actualizada, por lo que el paso # 6 no funcionará sin que el usuario B actualice y fusione previamente los cambios del usuario A. Honestamente. Intentalo.

supongo que lo que sucede en cambio, es la siguiente:

1. Un desprotege proyecto.
2. B revisa el mismo proyecto.
3. A agrega un archivo.
4. A confirma los cambios.
5. B agrega un archivo, pero se olvida de guardar el proyecto/solución.
6. B intenta confirmar los cambios y recibe un mensaje que debe actualizar primero.
7. B updates.
8. B vuelve a cambiar a VS. VS le dice que el proyecto/solución cambió en el disco y le pregunta si quiere a) volver a cargar desde el disco y perder sus cambios b) anular la versión en el disco.
9. B no entiende, no intenta comprender, considera que sus cambios son valiosos y elige b), anulando los cambios en el disco.
10. B todavía no intenta comprender y, por lo tanto, no difiere la versión que tiene en el disco con la última confirmada y, por lo tanto, no detecta que anuló los cambios de A.
11. B Comprueba, anulando los cambios de A.

He visto esto suceder de vez en cuando, generalmente con un usuario B que realmente no entiende el flujo de trabajo de SVN (o CVS ', FTM).

Así que aquí hay algunos consejos:

No actualizar a menos que haya guardado todo lo ("Archivo" -> "Guardar todo", para mí, eso es Ctrl + Shift + S). En caso de que haya cometido ese error y esté atascado, anule los cambios en el disco y luego fusione los cambios perdidos manualmente. (También podría funcionar actualizar el archivo proyecto/solución a la versión N-1, y luego a HEAD nuevamente, para que SVN realice la fusión.)

No confirmar sin verificar qué archivos cambiado y tiene un rápido mira en los diffs para ver si los cambios son los esperados.

Commit early, commit often. Cuantos más desarrolladores trabajen en la misma base de código, es más probable que tenga conflictos. Mientras más tiempo cambie su copia de trabajo sin actualizar, es más probable que tenga conflictos. Como el número de desarrolladores generalmente no está en sus manos, la frecuencia de actualización es lo único que puede usar para reducir la probabilidad de conflictos.

Answer 2

Una solución bastante radical pero eficiente es usar una herramienta para generar esos archivos de solución desde una meta-definición y luego poner meta-definición bajo control de fuente, no archivos de proyecto de Visual Studio (que son una pesadilla para fusionar) .

En mi equipo usamos MPC para hacer esto. Tenemos:

• un montón de archivos .mpc para la descripción de proyectos,
• un archivo .mwc para la descripción del espacio de trabajo/solución,
• una pequeña .cmd para generar archivos de Visual Studio.

Dado que todos son archivos de texto editados a mano, ya no tenemos problemas con Visual Studio mezclando todo.

Los inconvenientes son una herramienta adicional y la necesidad de regenerar los archivos de solución cuando se añaden o eliminan archivos, pero hay algunos beneficios adicionales también:

• configuraciones de proyectos están centralizados: por ejemplo, el cambio de una compilación la bandera se realiza en un solo lugar en lugar de hacerlo por proyecto,
• esto puede acomodar múltiples sistemas de compilación (actualmente utilizamos Visual 2003 y 2005, pero esto también funciona con gcc y otros).

Desde mi experiencia, aunque configurar la herramienta puede ser un poco doloroso (pero todo depende del tamaño y la complejidad de su proyecto), esto es claramente vale la pena.

Tenga en cuenta que MPC no es la única herramienta para este propósito. Existen otros, como CMake.

Answer 3

I second sbi's answer. Una posible solución es actualizar siempre desde Visual Studio, al menos si usa VisualSVN (no estoy seguro de cómo AnkhSVN resuelve esta situación).

VisualSVN bloqueará Visual Studio durante la operación de actualización, y se asegurará de que los proyectos modificados se vuelvan a cargar automáticamente, para que los usuarios no puedan ignorar los cambios externos.

Answer 4

También puede intentar reducir los conflictos asegurándose de que sus archivos de proyecto no enumeren todos los archivos individuales dentro del proyecto. Esto evitará que el archivo de proyecto se cambie en primer lugar cuando un usuario agregue un archivo.

Eres libre de utilizar comodines dentro de un archivo de proyecto: see MSDN

Ejemplo:

<ItemGroup> 
    <Compile Include="Src\**\*.cs" /> 
    [...] 
</ItemGroup> 

Es triste que Visual Studio no fomenta este tipo de configuración del proyecto y en su lugar opta por la lista archivos individuales

Answer 5

Esto es muy tedioso y tedioso, así que solo tiene que atravesarlo. A veces mantendrá la copia de trabajo local ya que tiene todos sus proyectos personalizados agregados. Sin embargo, en otros casos, querrá combinar todos los elementos nuevos de la solución Base para que pueda obtener todo lo que necesite de los dos archivos de la solución. Para facilitar la lectura, es mejor colocar todas las adiciones de productos base antes de las adiciones de personalización.

No se preocupe, la primera parte del GUID es idéntica para los proyectos, pero es la última parte que será única.

Fissh