Somos Subversion Geeks y queremos saber los beneficios de Mercurial [cerrado]

Después de leer que soy un geek de Subversion, ¿por qué debería considerar o no considerar Mercurial o Git o cualquier otro DVCS ?

Tengo una pregunta de seguimiento relacionada. Leí esa pregunta y leí los enlaces y videos recomendados y veo los beneficios, pero no veo el cambio mental general del que hablan las personas.

Nuestro equipo está formado por 8-10 desarrolladores que trabajan en una base de código grande que consta de 60 proyectos. Usamos Subversion y tenemos una troncal principal. Cuando un desarrollador inicia un nuevo caso de Fogbugz, crea una rama svn, hace el trabajo en la rama y cuando terminan se fusionan de nuevo con el tronco. Ocasionalmente, pueden permanecer en la rama por un tiempo prolongado y fusionar el tronco con la rama para recoger los cambios.

Cuando vi a Linus hablar sobre personas que creaban una sucursal y nunca más lo hacían, no éramos nosotros en absoluto. Creamos probablemente 50-100 sucursales a la semana sin problemas. El mayor desafío es la fusión, pero también hemos sido bastante buenos en eso. Tiendo a fusionarme por fogbugz case & checkin en lugar de la raíz completa de la rama.

Nunca trabajamos de forma remota y nunca hacemos ramas de las ramas. Si usted es el único que trabaja en esa sección de la base del código, entonces la fusión al tronco se realiza sin problemas. Si alguien más ha modificado la misma sección de código, la fusión puede ser complicada y es posible que deba realizar alguna cirugía. Los conflictos son conflictos, no veo cómo un sistema pueda hacerlo bien la mayor parte del tiempo a menos que sea lo suficientemente inteligente como para entender el código.

Después de crear una sucursal, el siguiente pago de 60k + archivos lleva algún tiempo, pero eso sería un problema con cualquier sistema de control de fuente que usaríamos.

¿Hay algún beneficio de cualquier DVCS que no estemos viendo y que nos sea de gran ayuda?

Para reformular su pregunta, "Si planeamos usar solo DVCS de manera centralizada, ¿qué beneficios tiene?" Cuando lo preguntas de esa manera, no lo hace. Una rama por tarea es extremadamente común en VCS. Si lo piensa, tener una copia local de trabajo del código fuente en la máquina de un desarrollador que cambia independientemente del tronco durante un día es una rama, a pesar de que nadie lo llama así. La única diferencia entre eso y su flujo de trabajo es que también le está dando a esas ramas un nombre permanente en el servidor central. Ese no es el tipo de ramificación de la que están hablando Linus y otros.

Para entender DVCS se requiere un cambio fundamental en el pensamiento. Tienes que preguntarte qué harías con tantas ramas como quieras que se compartan con quien quieras, y solo con ellas. Eso incluye ramas que solo tú puedes ver.

Las posibilidades son infinitas. Por un solo ejemplo, ¿qué tal dos personas trabajando en lados opuestos de una interfaz? Necesitan compartir código entre sí regularmente, pero aún no es lo suficientemente estable como para compartirlo con todos. Pueden crear una rama para compartir entre ellos y luego fusionarla nuevamente en el repositorio central cuando esté lista.

La capacidad de realizar compromisos locales intermedios lo vale todo por sí solo. Eso es algo que solo tienes que experimentar por ti mismo.

La velocidad obtenida de tener su repositorio local también vale todo por sí mismo. Sí, el clon inicial será inevitablemente lento en cualquier VCS para un repositorio de archivos de 60k, pero una vez que tenga eso, verificar una nueva rama es mucho más rápido con un DVCS.

Para su caso particular, no hay ningún beneficio en cambiar a un DVCS. Estás contento con tu sistema existente, hace todo lo que necesitas, así que ¿por qué cambiar? SVN sigue siendo un proyecto activo de código abierto y tiene integraciones mejores y más maduras con todos los IDE y herramientas de desarrollo más importantes que hg o git. Dado el tamaño de su equipo y la cantidad de proyectos, ¿realmente desea tomarse el tiempo para convertirse en una nueva herramienta cuando la existente funciona bien?

Si tiene desarrolladores que simplemente no pueden funcionar sin un DVCS, apúntelos a las puertas de enlace svn para hg o git. Deje en claro para ellos que sus registros en el repositorio svn deben ajustarse a los procedimientos y procesos que utilice el resto del equipo. Otra ventaja de este enfoque es que los verdaderos fanáticos de DVCS que ya están usando las puertas de enlace sin decirte que ahora pueden salir del armario :-).

Me parece que ya está usando un flujo de trabajo que es muy similar al tipo de flujo de trabajo que muchas personas adoptan después de comenzar a usar un DVCS.

Desde su punto de vista, un DVCS tendrá las siguientes ventajas significativas sobre SVN:

• Una vez que haya clonado sus repositorios, se pueden realizar muchas operaciones localmente.
  • Mirar el registro del repositorio no necesita tocar el servidor svn, por lo que puede ser increíblemente rápido.
  • Del mismo modo, el cambio de sucursales no requiere acceso al servidor, ni los clones locales.
• Debido a que las ramas son solo rutas divergentes a través de la historia, su repositorio no está abarrotado de todas las ramas que alguien haya creado (solo tenemos ramas de lanzamiento en SVN, pero el branchesdirectorio todavía tiene muchos subdirectorios que ya no son relevantes).
  • En git, una vez que se ha fusionado una rama y se ha eliminado la referencia, es posible que nunca sepas que estaba allí.
  • En Mercurial tiene la opción de nombrar una rama (en cuyo caso está codificada en cada conjunto de cambios a perpetuidad) o simplemente crear una rama sin nombre (topológica), que se fusionará silenciosamente en el historial cuando mergevuelva a estar en default( trunk)
• En SVN, las ramas de las ramas son demasiado oscuras para ser útiles. En gity hgestán a la par para el curso.
• DVCS entiende que el desarrollo de software es un DAG , es decir, cuando se fusiona, termina con un conjunto de cambios con varios padres. SVN (al menos la versión que he usado) realmente no entiende esto.

En ese último punto, dices

Los conflictos son conflictos, no veo cómo ningún sistema podría hacerlo bien la mayor parte del tiempo a menos que fuera lo suficientemente inteligente como para entender el código.

Al cambiar de usar hgexclusivamente a usar svnsolo y gitsvn, según mi experiencia, las fusiones son mucho más simples y sin problemas con hgy gitsvnde lo que son svn. Las fusiones con svn(al menos la versión que usamos) producen significativamente más conflictos que deben resolverse manualmente.

Una de las razones por las que las fusiones son más difíciles en SVN es que solo le da dos opciones para cada línea que difiere,

• el texto de la rama en la que te estás fusionando
• el texto de la rama en la que te estás fusionando

mientras que las fusiones de un DVCS generalmente le darán una tercera opción, que es

• el texto del ancestro común de ambas ramas que estás fusionando

No subestimes lo beneficioso que es esto, te proporciona un contexto mucho mejor para los cambios que un simple diferencial de dos vías.

En general, te sugiero que lo pruebes. Con herramientas como gitsvny hgsubversion, incluso puedes probarlas con tus repositorios SVN actuales .

^{Tenga en cuenta que crear el clon en primer lugar es una PItA real, pero una vez que lo haya hecho, obtendrá la mayor parte del poder de un DVCS con su CVCS existente.}

Hay un cambio importante que he notado después de tal transición: cambio las ramas con mucha más frecuencia y me comprometo con más frecuencia de lo que podría permitirme con Subversion. Por ejemplo, hay una serie de pequeñas ramas de funcionalidad, organizadas en una secuencia, y puedo pasar meses agregando bits a cada una de ellas, volviendo a clasificarlas fácilmente en secuencia en un tronco siempre cambiante. Reorganizar el orden en que se fusionan las ramas de funcionalidad es trivial.

Pero, de hecho, en realidad no me he alejado de Subversion. Solo estoy usando git como mi cliente svn local.