¿Las fusiones en subversión son más difíciles que en Team Foundation System?

Estoy acostumbrado a usar TFS, y mi compañía ahora está cambiando a SVN para un nuevo proyecto (la razón principal es incorporar mejor nuestra base de código java & .Net bajo el mismo control de fuente).

Me dan entender que las fusiones en subversión son difíciles (Jeff lo mencionó en su último podcast).

  1. ¿Cuáles son los problemas con la subversión, en comparación con TFS?
  2. Cómo mitigar? (dentro de los límites de la subversión, o como Jeff propuso, elegir otro control de fuente)

Una característica importante que ofrece TFS es su capacidad de automation (mejorada en gran medida en TFS2008, aunque todavía no es perfecta). La mayoría de las fusiones no requieren ninguna acción por parte del usuario. ¿Es eso lo mismo en la subversión?

Actualización : una respuesta aceptada aquí solo puede provenir de alguien que haya experimentado grandes fusiones tanto en TFS como en subversión , y que realmente pueda compararlas y contrastarlas. Saber que "fusionarse en subversión es bueno" o "TFS es una mierda" realmente no me ayuda a decidir, porque es subjetivo. Si puede comparar con otras alternativas, genial, es útil. Pero mi enfoque es la subversión vs TFS.

El tamaño del equipo objective que me interesa es 6-30 desarrolladores activos.

Actualización 2 : ¿hay alguien que pueda argumentar que las fusiones en SVN son de hecho más fáciles que en TFS (teniendo en count las herramientas)?

He realizado grandes fusiones tanto en TFS como en Subversion. La base de código TFS era una twig 1.5-> 2.0 de una aplicación de SharePoint con cambios de producción fusionados en la base de código 2.0. La fusión de SVN fue una fusión de nuevas características desde una bifurcación en la fuente de reference.

Ya está familiarizado con TFS, por lo que le ahorraré los detalles, aparte de decir que los sets de cambios y las herramientas TFS simplificaron el process. Obtuvimos el error TF14087 debido a un problema de recuperación, pero se resolvió rápidamente.

En SVN, el process fue bastante más manual porque teníamos que apuntar a versiones específicas de los files en SVN, y SVN hizo una diferencia en los files que no nos permitía la flexibilidad que experimentamos con los sets de cambios en TFS (casos como "no todos los cambios en ChangesetA pero todos los cambios en ChangesetB "). No teníamos el seguimiento de fusión en ese momento, ni nuestro tree fuente estaba diseñado para admitir las mejores prácticas de seguimiento de fusión de SVN.

Creo que ahora, con el seguimiento de fusión en SVN, el process sería bastante más simple si se asume que se siguen las mejores prácticas descritas por CollabNet. Pero tenga en count que TFS es un gran producto con herramientas de GUI realmente geniales para administrar su fuente, mientras que SVN depende más de la command-line, por lo que esto complica las cosas si está acostumbrado a trabajar con la GUI.

No creo que las fusiones en subversión sean difíciles en los casos comunes, eche un vistazo a ejemplos como estos . Me he encontrado fusionando deliciosamente simple y fácil; aunque algunos compañeros de trabajo se quejan de que les gusta más CVS, otros p4, etc. Sospecho que gran parte de esto tiene que ver con la familiaridad con otras herramientas, no con la superioridad / superioridad técnica.

Puede ser que las fusiones más complicadas (de tres vías) sean más difíciles, pero la pregunta es si las de uso común son esas. Personalmente, considero que las fusiones complicadas (y las twigs de larga vida, el seguimiento complejo de las sucursales y las estrategias de fusión, etc.) huelen a podnetworkingumbre de código (o supongo que SCM se pudrirá). YMMV.

No estoy familiarizado con TFS, pero hasta la versión 1.5, el soporte de fusión de Subversion consistía en poco más que tomar el diferencial de un range de revisiones (especificado manualmente) y aplicarlo a otra ruta en el repository. Con la versión 1.5, se implementó el seguimiento de fusión, pero parece ser bastante complejo con casos de borde interesantes.

Si la fusión es crítica para usted, es posible que desee considerar uno de los DVCS que se destacan en la fusión, como git o mercurial .

He usado la subversión durante mucho time, y déjame decirte que la fusión es horrible y está completamente rota. He cambiado a mercurial, a pesar de que no tengo uso para las cosas distribuidas, solo para get una ramificación que funcione.

Elaboración, según lo solicitado Para fusionarse con éxito en SVN, necesita (ed) conocer el número de versión que llevaba la twig, que no es tan difícil de encontrar, siempre y cuando solo realice una sola fusión en el tronco. Desafortunadamente, algunas veces necesita fusionarse varias veces (es decir, para agregar una característica que primero tuvo que corregir un error) en el tronco, o está fusionándose entre diferentes twigs, lo que hace que sea imposible realizar un seguimiento de la versión número pertenece a qué twig y qué se ha fusionado previamente.

La versión de SVN que uso es 1.5.1, por lo que debería funcionar con el nuevo desarrollo de estilo, aunque parece que no lo hice.

Algo fuera de tema, pero si la cuestión de pasar de TFS para tus desarrolladores de java aún está en el air, te recomendaría que busques en Teamprise. Es una herramienta creada solo para desarrolladores de Java que usan TFS. Le da al usuario de Java la mayor parte del poder de la integración de Visual Studio (y algunas cosas incluso mejores) dentro de Eclipse.

http://www.teamprise.com/

(Para su información, no estoy afiliado a ellos de ninguna manera …)

Vaccano

Hay pros y contras de todos los sistemas.

Pero una pequeña nota útil (que está cerca del tema fuera de tema) es que un poderoso progtwig de fusión / diferencia externa a menudo es realmente útil. Entonces, sea lo que sea que elija, asegúrese de tener una buena herramienta de combinación de 3 vías para ayudar cuando se rompe el material automatizado.

BR Johan