visual-studio - para - tortoise svn plugin for visual studio 2017

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

¿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

El usuario A revisa el proyecto
El usuario B revisa el mismo proyecto
El usuario A agrega un archivo
El usuario A confirma los cambios
El usuario B agrega un archivo
El usuario B comete cambios

Me parece que en el paso (6), svn, Tortoise, Ankh o lo que sea debería detectar un conflicto y fusionar los dos archivos de proyecto automáticamente o, más probablemente, solicitar 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.

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

En mi equipo usamos MPC para hacer esto. Tenemos:

un grupo de archivos .mpc para descripciones de proyectos,
un archivo .mwc para la descripción del espacio de trabajo / solución,
un pequeño .cmd para generar archivos de Visual Studio.

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

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

las configuraciones del proyecto están centralizadas: por ejemplo, cambiar un indicador de compilación 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 claramente lo vale.

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

Respondo la segunda respuesta de sbi. 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, de modo que los usuarios no puedan ignorar los cambios externos.

¿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 n.º 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 esto:

Un proyecto de verificación.
B revisa el mismo proyecto.
A agrega un archivo.
A comete cambios.
B agrega un archivo, pero olvida guardar el proyecto / solución.
B intenta realizar cambios y recibe un mensaje que debe actualizar primero.
B actualizaciones.
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.
B no entiende, no trata de entender, considera que sus cambios son valiosos, y elige b), anulando los cambios en el disco.
B todavía no intenta comprender y, por lo tanto, no difiere la versión que tiene en el disco con la última comprometida y, por lo tanto, no puede anular los cambios de A.
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 actualice a menos que haya guardado todo ("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 de proyecto / solución a la versión N-1, y luego a HEAD nuevamente, para que SVN realice la fusión).

No se comprometa sin verificar qué archivos ha cambiado y echando un vistazo rápido a los diffs para ver si los cambios son los esperados.

Comprométase temprano, comprométase a menudo . 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.

También puede intentar reducir los conflictos asegurándose de que sus archivos de proyecto no incluyan 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.

Puede usar comodines dentro de un archivo de proyecto: vea MSDN

Ejemplo:

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

Es triste que Visual Studio no aliente este tipo de configuración de proyecto y en su lugar opte por listar archivos individuales.

Esto es muy tedioso y tedioso, así que solo tienes 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