¿Por qué es más fácil bifurcar y fusionar en Mercurial que en Subversion?

Question

Manejar múltiples fusiones en ramas en Subversion o CVS es solo una de esas cosas que hay que experimentar.Es excesivamente más fácil realizar un seguimiento de las ramas y fusiones en Mercurial (y probablemente en cualquier otro sistema distribuido), pero no sé por qué.¿Alguien más lo sabe?

Mi pregunta surge del hecho de que con Mercurial puedes adoptar una práctica de trabajo similar a la del repositorio central de Subversions/CVS y todo funcionará bien.Puede realizar múltiples fusiones en la misma rama y no necesitará interminables trozos de papel con números de confirmación y nombres de etiquetas.

Sé que la última versión de Subversion tiene la capacidad de rastrear fusiones en sucursales para que no tengas el mismo grado de molestia, pero fue un desarrollo enorme e importante de su parte y todavía no hace todo lo que haría el equipo de desarrollo. gusta que lo haga.

Debe haber una diferencia fundamental en la forma en que funciona todo.

Answer 1

En Subversion (y CVS), el repositorio es lo primero y lo más importante.En Git y Mercurial no existe realmente el concepto de un repositorio de la misma manera;Aquí los cambios son el tema central.

+1

La molestia en CVS/SVN proviene del hecho de que estos sistemas no noRecuerda la paternidad de los cambios.En GIT y Mercurial, no solo un compromiso puede tener varios hijos, ¡sino que también puede tener múltiples padres!

Eso se puede observar fácilmente usando una de las herramientas gráficas, gitk o hg view.En el siguiente ejemplo, la Rama #2 se bifurcó del #1 en el comité A, y desde entonces se ha fusionado una vez (en M, se fusionó con el commit b):

o---A---o---B---o---C         (branch #1)
     \       \
      o---o---M---X---?       (branch #2)

Observe cómo A y B tienen dos hijos, mientras que M tiene dos padres.Estas relaciones son grabado en el repositorio.Digamos que el mantenedor de la Rama #2 ahora quiere fusionar los últimos cambios de la Rama #1, pueden emitir un comando como:

$ git merge branch-1

y la herramienta sabrá automáticamente que el base es B, porque se registró en Commit M, un antepasado de la punta del #2, y que tiene que fusionar lo que sucedió entre B y C.CVS no registra esta información, ni SVN antes de la versión 1.5.En estos sistemas, el gráfico se vería como:

o---A---o---B---o---C         (branch #1)
     \    
      o---o---M---X---?       (branch #2)

Donde M es solo un gigantesco compromiso "aplastado" de todo lo que sucedió entre A y B, aplicado sobre M.Tenga en cuenta que una vez realizada la escritura, hay No queda rastro (excepto potencialmente en comentarios legibles por humanos) de donde M se originó, ni de cuántos Los compromisos se colapsaron juntos, haciendo historia mucho más impenetrable.

Peor aún, realizar una segunda fusión se convierte en una pesadilla:Uno tiene que averiguar cuál era la base de fusión en el momento de la primera fusión (y una tiene a saber¡Que ha habido una fusión en primer lugar!), Luego presente esa información a la herramienta para que no intente reproducir A..B encima de M.Todo esto es bastante difícil cuando se trabaja en una colaboración cercana, pero es simplemente imposible en un entorno distribuido.

Un problema (relacionado) es que no hay forma de responder a la pregunta:"¿X contiene B?" donde B es una solución de error potencialmente importante.Entonces, ¿por qué no solo registrar esa información en la confirmación, ya que es conocido ¡en el momento de la fusión!

PD.- No tengo experiencia con las habilidades de grabación de fusiones SVN 1.5+, pero el flujo de trabajo parece estar mucho más artificial que en los sistemas distribuidos.Si ese es realmente el caso, probablemente sea porque, como se menciona en el comentario anterior, se centra en la organización de repositorio en lugar de los cambios en sí.

Answer 2

Porque Subversion (al menos la versión 1.4 e inferiores) no realiza un seguimiento de lo que se ha fusionado.Para Subversion, la fusión es básicamente lo mismo que cualquier confirmación, mientras que en otros controles de versión como Git, se recuerda lo que se ha fusionado.

Answer 3

Sin verse afectado por ninguna de las respuestas ya proporcionadas, Hg ofreció capacidades de combinación superiores porque utiliza más información al fusionar cambios (hginit.com):

Por ejemplo, si cambio un poco una función, y luego lo muevo a otro lugar, la subversión realmente no recuerda esos pasos, por lo que cuando llega el momento de fusionar, podría pensar que una nueva función simplemente apareció de la nada .Mientras que Mercurial recordará esas cosas por separado:La función cambió, la función se movió, lo que significa que si también cambió esa función un poco, es mucho más probable que Mercurial fusione con éxito nuestros cambios.

Por supuesto, recordar qué se fusionó por última vez (el punto abordado por la mayoría de las respuestas proporcionadas aquí) también es una gran victoria.

Ambas mejoras, sin embargo, son cuestionables ya que Subversion 1.5+ almacena información de combinación adicional en forma de propiedades de Subversion:Con esa información disponible, no hay ninguna razón obvia por la que Subversion merge no pueda implementar la combinación con tanto éxito como Hg o Git.No sé si es así, pero ciertamente parece que los desarrolladores de Subversion están en camino de solucionar este problema.

Answer 4

Supongo que esto podría deberse en parte a que Subversion tiene la idea de un servidor central junto con una línea de tiempo absoluta de revisiones.Mercurial está verdaderamente distribuido y no tiene tal referencia a una línea de tiempo absoluta.Esto permite que los proyectos de Mercurial formen jerarquías de ramas más complicadas para agregar funciones y ciclos de prueba por subproyecto; sin embargo, los equipos ahora necesitan mantenerse mucho más activos al tanto de las fusiones para mantenerse actualizados, ya que no pueden simplemente presionar actualizar y terminar con ello. .

Answer 5

En Subversion (y CVS), el repositorio es lo primero y lo más importante.En git y mercurial realmente no existe el concepto de repositorio de la misma manera;aquí cambios son el tema central.

Tampoco he pensado mucho en cómo lo implementarías, pero mi impresión (basada en una amarga experiencia y mucha lectura) es que esta diferencia es lo que hace que la fusión y la ramificación sean mucho más fáciles en sistemas que no están basados ​​en repositorios.

Answer 6

Sólo tengo experiencia con Subversion pero puedo decirles que la pantalla de combinación en TortoiseSVN es terriblemente complicada.Por suerte incluyen un botón de ejecución en seco para que puedas ver si lo estás haciendo bien.La complicación está en la configuración de qué quieres fusionar y dónde.Una vez que haya configurado la fusión, ésta generalmente funcionará bien.Luego, debe resolver todos y cada uno de los conflictos y luego enviar su copia de trabajo fusionada al repositorio.

Si Mercurial puede facilitar la configuración de la fusión, entonces puedo decir que la fusión sería 100% más fácil que Subversion.