Merges parciales?

Merges parciales?

1:11 1 Comments

El tema, al primer vistazo, puede sonar un poco rebuscado, así que voy a intentar simplificarlo al máximo.

¿Qué es un merge parcial?

Hacer un “merge parcial” consiste en, dada una rama o un changeset (commit, en términos Hg/Git) que se denominará “origen del merge” (src), hacer “merge” (o integrar) en una rama destino sólo parte de los elementos modificados en el origen del merge. Con una imagen seguro que se entiende mejor:

El “ninja coder” ha modificado unos cuantos ficheros en una rama, ¿qué pasaría si sólo quiere integrar render.c y readme.txt pero ser capaz de integrar el resto más tarde?

Nota: Las "flechas" entre changeset y changeset indican "parentesco". Es decir, el cset 0 es padre del cset 1. Las flechas indican parentesco y no secuencia, al estilo de lo que Scott Chacon dibuja en Getting Git (slide 165). Por cierto, es también como nuestro branch explorer de 4.0 dibuja las cosas.

Objetivo

Mi objetivo con este post es: que me enviéis vuestra opinión sobre la importancia, o no, de los "merges parciales" en vuestro equipo. Podéis dejar comentarios en este post o bien contribuir a este thread de stackoverflow: http://stackoverflow.com/questions/7323662/dvcs-partial-merge-git-hg-merge-tracking

¿Por qué esto es importante?

Para algunos de vosotros quizá la explicación de arriba os suena ya a hablar de un caso rebuscado. ¡No sabéis cuánto me alegro! Me alegro porque quiere decir que no necesitáis merges parciales, lo que me simplifica mucho la vida. Los merges parciales son importantes porque todos los DVCS (Distributed Version Control System) como Git o Mercurial (Hg) carecen de merge parcial. ¿Es esa una enorme carencia? Es lo que me gustaría que me contaseis.

Para los usuarios de Subversion que se están riendo…

… con una risa contagiosa y malvada diciendo “ya os lo decía yo, los DVCS esos son una patata, mejor quedarse con el viejo SVN!!”. Vale, ¡estáis listos! Esto de los merges parciales afecta a sistemas como Git o Hg (que no lo tienen) frente a sistemas como Clearcase o nuestro Plastic <=3… vosotros, queridos usuarios de SVN, no tenéis este problema… ¡¡estáis todavía peor!!

En detalle

Vamos a ver qué significa eso de los merges parciales, con imágenes:

Primero el “ninja coder” hace un merge de dos de los cuatro ficheros que modificó. Luego:

Un sistema sin “merge parcial” con trazabilidad a nivel de changeset, crea un “merge link” entre changesets que se han mezclado, pero no tiene modo de saber si todo el contenido (todos los ficheros) fue mezclado o no. Asume siempre que el contenido completo fue mezclado.

Un sistema con “merge parcial” (como lo era Plastic SCM hasta 4.0) identifica la historia de merge ítem por ítem mientras que en los DVCS modernos la “trazabilidad de merge” va a nivel de changeset. Implica que hay muchos cálculos (uno por fichero) en lugar de uno sólo para todos.

¿Cómo es de importante?

¿Integras primero partes de una rama y luego el resto? Si es así, o cambias de método de trabajo o el sistema de merge “parcial” no servirá demasiado.

Ventajas y desventajas

No soportar “merges parciales” hace que el mecanismo de merge de ramas sea mucho más rápido. La desventaja es que no es sencillo (se puede hacer dividiendo changesets) mezclar sólo parte de una rama.

Opiniones

En la beta de 4.0 (igual que en todos los DVCS incluyendo Git y Hg) el merge tracking es a nivel de cset, lo que implica que no hay soporte para merges parciales.

Enviadnos opiniones para saber cómo de importante es soportar merge parcial y actuar en consecuencia!

Como decía: podéis dejar comentarios en este post o bien contribuir a este thread de stackoverflow: http://stackoverflow.com/questions/7323662/dvcs-partial-merge-git-hg-merge-tracking