Ayuda a comprender los beneficios de la ramificación en Mercurial

Question

Me costó entender cómo la ramificación es beneficiosa. No puedo presionar a un repositorio con 2 cabezas, o 2 ramas ... entonces ¿por qué alguna vez los necesitaría/usaría?

Answer 1

En primer lugar, puede empujar incluso con dos cabezales, pero como probablemente no quiera hacer eso, el comportamiento predeterminado es evitar que lo haga. Sin embargo, puedes forzar el empuje para pasar.

Ahora, en cuanto a la bifurcación, veamos un escenario simple en un sistema de control de versiones no distribuidas, como Subversion.

Supongamos que tiene un colega que está trabajando en el mismo proyecto que usted. El último conjunto de cambios actual en el repositorio de Subversion es la revisión 100, ambos lo actualizan localmente para que ahora ambos tengan los mismos archivos.

Ok, ahora su colega ya ha estado trabajando en sus cambios durante un par de horas, por lo que se compromete. Esto lleva el repositorio central a la revisión 101. Todavía está en revisión 100 localmente, y todavía está trabajando en sus cambios.

En algún momento, completa y desea comprometerse, pero Subversion no lo permitirá. Dice que primero debe actualizar, para que comience el proceso de actualización.

El proceso de actualización desea tomar sus cambios y pretender que realmente comenzó con la revisión 101 en lugar de 100. Si sus cambios no están en conflicto con lo que fue su colega cometido, todo es Hunky Dory, pero si sus cambios son en conflicto, usted tiene un problema.

Ahora tiene que fusionar los cambios con sus cambios, y las cosas pueden volverse locas. Por ejemplo, puede terminar fusionando un archivo OK, el segundo archivo OK, o eso cree, y luego el tercer archivo, y de repente descubre que tiene algunos de los detalles incorrectos, hubiera sido mejor fusionar el segundo archivo de manera diferente.

A menos que haya hecho una copia de seguridad de sus cambios antes de actualizar, y tarde o temprano se olvidará, usted tiene un problema.

Ahora, el escenario anterior es en realidad bastante común. Bueno, tal vez no sea la parte de fusión, depende de cuántos está trabajando en la misma área o archivos al mismo tiempo, pero la parte "debe actualizarse antes de comprometerse" es bastante común con Subversion.

Entonces, ¿cómo lo hace Mercurial?

Bueno, Mercurial se compromete localmente, no habla a ningún repositorio remoto, por lo que no le impedirá comprometerse.

Entonces, intentemos el escenario anterior otra vez, solo en Mercurial esta vez.

El conjunto de cambios tipmost en el repositorio remoto es la revisión 100. Los dos tienen clonado esto abajo, y ambos estamos empezando a trabajar en los cambios, desde la revisión 100.

Su colega completa sus cambios y se compromete, en la zona. Luego empuja su conjunto de cambios hasta el repositorio central, llevando la sugerencia hasta la revisión 101.

Luego completa los cambios y confirma, también localmente, y luego desea enviar, pero aparece el mensaje de error que Ya he descubierto, y está preguntando sobre.

¿Cómo es esto diferente?

Bueno, los cambios se han confirmado, no hay forma, a menos que intente realmente accidentalmente perderlos o destruirlos.

aquí está el 3 repositorios en juego y su estado actual:

Colleague  ---98---99---100---A 

Central   ---98---99---100---A 

You    ---98---99---100---B 

Si se va a empujar, y se le permitió hacer esto (o forzar el empuje a través), el repositorio central se vería así:

Central   ---98---99---100---A 
           \ 
           +--B 

Two heads. Si su colega ahora se retira, ¿de cuál debería continuar trabajando? Esta pregunta es la razón por la cual Mercurial evitará que usted cause esto de manera predeterminada.

Así que, en su lugar, tira y obtiene el estado anterior en su propio repositorio.

En otras palabras, puede optar por afectar su propio repositorio y crear varias cabezas allí, pero no está imponiendo ese problema a nadie más.

Luego se fusiona, el mismo tipo de operación que tuvo que hacer en Subversion, excepto que su conjunto de cambios es seguro, se cometió y no lo corromperá ni destruirá accidentalmente. Si, en mitad de la fusión, quieres comenzar de nuevo, puedes, nada perdido, ningún daño hecho.

Después de la fusión, su repositorio local se ve así:

You    ---98---99---100---A----M 
           \  /
           +--B--+ 

Esto es ahora segura para empujar, y si su colega ahora tira, él sabe que tiene que continuar desde el conjunto de cambios M, el uno que fusionó su y sus cambios.

La descripción anterior es lo que sucede debido a la naturaleza distribuida de Mercurials.

También puede nombrar ramas, para hacerlas más permanentes. Por ejemplo, es posible que desee nombrar una rama "estable", para indicar que cualquier conjunto de cambios en esa rama se ha probado exhaustivamente y es seguro para liberar a los clientes o ponerlo en producción. Entonces solo fusionaría los cambios en esa rama cuando dicha prueba haya sido completada.

La naturaleza, sin embargo, es la misma que la descripción anterior. Cada vez que más de una persona trabaje en un proyecto con Mercurial, obtendrá ramas, y eso es algo bueno.

Answer 2

Cada vez que se realiza más de un clon de un repositorio y se realizan confirmaciones en esos clones, se producen ramificaciones, ya sea que los nombre utilizando el comando hg branch o no. Mi filosofía es que podrías darles un nombre. Hace las cosas menos confusas.

Una buena explicación de las ramas mercuriales: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/