Visual Studio 2008: ¿cómo evitar el infierno de fusión de archivos de proyecto?

Cuando trabajas en un proyecto VS C# con múltiples desarrolladores que agregan nuevos proyectos y archivos a la misma solución, el último en probar y verificar sus cambios genera conflictos en el archivo de solución del proyecto que no son fáciles de combinar .Visual Studio 2008: ¿cómo evitar el infierno de fusión de archivos de proyecto?

La solución más fácil a este problema que he encontrado es descartar mis propios cambios y aceptar la última versión del servidor. Luego reintegro mis propios cambios. Dependiendo de la cantidad de archivos nuevos agregados al proyecto, esto puede ser fácil o una tarea realmente molesta.

Me pregunto si hay una manera más fácil de hacer esto. Leer: ¿puedo hacer que VS/TFS/merge haga esto por mí?

Fuente

2010-03-16 n3wjack

Lo difícil acerca de cómo combinar archivos XML? –

Auto fusión no es tan malo en el manejo de los archivos de proyecto en mi experiencia, y ofrece esa opción para usted (que actualmente está descartando!). –

¿Con qué frecuencia está agregando proyectos? Agregar proyectos a una solución no debe ser una tarea diaria cuando su arquitectura se presenta por adelantado. Tal vez incluso deberías establecer como regla que los desarrolladores deben preguntar al desarrollador o arquitecto principal si se puede agregar un proyecto. Incluso agregar archivos debería ser bastante raro. – Steven

Mi sugerencia sería actualizar y confirmar con más frecuencia. En particular, asegúrese de ejecutar Get Latest antes de cualquier cambio en un archivo de solución.

"Combinar infierno" con cosas como archivos de texto y XML (que son todos los archivos de proyectos y soluciones) normalmente solo se produce porque las personas intentan realizar cambios individuales que son muy grandes.

Si adquiere el hábito de realizar confirmaciones regulares, las fusiones tienden a ser más pequeñas, y las herramientas tienden a hacer un trabajo perfecto de la misma.

Fuente

2010-03-16 16:52:00

También le sugiero que haga que su gente se sienta cómoda al detenerse y hacer preguntas si no está seguro de cómo fusionar un archivo de solución. Trabajé en un lugar donde varias veces por semana tendría que limpiar manualmente el archivo de la solución porque las personas automatizarían en lugar de verificar los resultados. (Y el SLN no es XML.) –

@Reed, no estoy de acuerdo. ¿Realmente ha ejecutado una herramienta automotriz contra un archivo * .sln donde dos personas han agregado nuevos proyectos? Literalmente, no hay forma de que tenga éxito debido a la forma en que se asignan los números a los proyectos. –

@Richard: si actualiza y se compromete con frecuencia, esto nunca debería suceder. Personalmente, hago que mi equipo siempre se actualice antes de una confirmación. Personalmente, creo que un nuevo proyecto que se agrega debe ser un compromiso propio. Esto significa que actualizas, comprometes cualquier cambio. A continuación, agregue su proyecto y comprométalo. Básicamente, NUNCA debes tener dos proyectos "nuevos" para fusionar, a menos que dos personas intenten agregar un nuevo proyecto dentro del mismo margen de tiempo de unos minutos (muy poco probable) ... –

Nunca agrego archivos a la Solución, solo proyectos. Si necesita agregar archivos, agréguelos a un proyecto.

Si no desea fusionarse, la alternativa es si alguien revisa una solución con un nuevo proyecto, luego extraiga ese proyecto y la solución, sobrescribiendo su propio archivo de solución, luego vuelva a agregar su proyecto a la solución y verifique que regresen. Ahora la solución tiene tanto su proyecto como el suyo.

Fuente

2010-03-16 16:54:16 AaronLS

Algunos archivos son buenos para tener uno como referencia. Los ejemplos que he usado en el pasado serían ensamblajes de terceros, claves de nombres fuertes, notas generales y archivos de configuración compartidos. –

Los coloco en un proyecto vacío. El problema es que las carpetas "virtuales" utilizadas por las soluciones pueden causar inconsistencias entre las máquinas. Cuando revisa la solución y los archivos en una máquina diferente, es posible que no estén en la misma estructura de directorio relativa que eran para el desarrollador que agregó los archivos. Las soluciones también permiten referencias a archivos como ".. \ .. \ OutsideFolder" que pueden crear estragos cuando otro desarrollador intenta extraer la solución del control de origen. – AaronLS

Estoy de acuerdo con aaronis en que debes tener cuidado con las rutas relativas. Sin embargo, es bastante normal agregar montajes de terceros a la solución, como explica Matthew. Lo que siempre hago es crear un directorio llamado 'Shared Assemblies' para los dlls de terceros en el directorio de soluciones y crear una carpeta de soluciones con el mismo nombre. De esta manera, nunca tengo ninguno de los problemas que aaronis describe. – Steven

Una sugerencia para añadir a la piscina de los comentarios ...

trabajo en la minimización de los cambios que realice en el archivo SLN cuando se comprometa, para que sea más fácil para que otros se fusionan.

(Por supuesto, lo mismo ocurre con los otros también).

Para ilustrativos, supongamos que su archivo SLN enumera actualmente cuatro proyectos:

SLN: A, B, C, D

Usted y un compañero de trabajo tanto hacer cambios. Agrega proyecto E, más (por alguna razón) las cosas se reordenan:

Yours: A, E, D, C, B

sus compañeros de trabajo cambios implican la adición de proyecto F:

Co-Worker: A, B, C, D, F

Si envíe sus cambios como es, entonces sus co -el trabajador tiene que enfrentar la fusión de estos dos:

SLN: A, E, D, C, B 
Co-Worker: A, B, C, D, F

Nasty.

En cambio, si (¡con cuidado!) Trabaja para minimizar sus diferencias, puede hacer que su copia de trabajo el siguiente aspecto:

Yours: A, B, C, D, E

En este caso, cuando su compañero de trabajo tiene que fusionar, tendrán que hacer frente a este:

SLN: A, B, C, D, E 
Co-Worker: A, B, C, D, F

Mucho más fácil de combinar.

Fuente

2010-03-17 21:01:02 Bevan

Yo también estaba harto de combinar problemas con los archivos del proyecto. (En un momento yo estaba tratando de resolver los conflictos de 9000 en un único archivo de proyecto.)

Así que hizo algo al respecto: http://www.projectmerge.com

Aunque esto comenzó como un archivo de proyecto comparar/fusionar herramienta, de forma rápida evolucionado en algo que puede comparar y fusionar cualquier archivo XML.

Espero que lo encuentres útil.

Fuente

2010-08-14 15:03:03

Hice una herramienta específicamente para comparar/fusionar archivos de soluciones (y también se puede usar para crear dinámicamente soluciones filtradas).

Se puede encontrar en: http://slntools.codeplex.com/

Fuente

2010-09-02 17:27:53

Wow, gracias, intentaré esto. ¡Deséame suerte! – toddmo

Acabo de salvarme un montón de headbanging. Gracias :) –

Visual Studio 2008: ¿cómo evitar el infierno de fusión de archivos de proyecto?

Respuesta

Cuestiones relacionadas