mercurial repository tutorial

¿Cuál es la mejor manera de cerrar una rama Mercurial? (3)

¿Es mejor cerrar primero una rama y luego fusionarla con la rama predeterminada (por ejemplo) o primero fusionarla y luego cerrarla?

En TortoiseHg, por ejemplo, en el primer caso, verá una línea desde un nodo cercano a la rama predeterminada. En el segundo caso, verá una línea desde el último compromiso hasta la sucursal predeterminada y una línea adicional desde el último compromiso hasta un nodo cercano.

Espero que esté claro. Tal vez es una cuestión de gusto ...

No hay una diferencia real entre los dos métodos cuando se habla de ramas con nombre, al menos en cualquier versión reciente de Mercurial. Las cosas eran diferentes antes de 1.5 (?), Pero puramente en el hecho de que hg heads y hg branches incluirían estas ramas "cerradas" en su salida; aún pueden -c si especifica -c en el comando.

Recuerde que cuando cierra una bifurcación (utilizando hg commit --close-branch o en Tortoise) efectivamente solo compromete un nuevo conjunto de cambios donde el cambio tiene una bandera configurada para decir que la rama X está cerrada - puede actualizar fácilmente a la rama y vuelva a abrirlo realizando otra confirmación.

Sin embargo, cuando vuelva a abrir una sucursal, la "barra" que ve en Tortoise seguirá existiendo en el conjunto de cambios previamente cerrado, y por este motivo yo personalmente optaría por una política de cierre y fusión. Es más visualmente instructivo, creo, ver que te estabas uniendo a algo con lo que estabas feliz (y por lo tanto, cerraste la rama antes de la fusión).

Las cosas son ligeramente diferentes con las ramas "anónimas", ya que no están incluidas en la salida de las hg branches cuando se fusionaron, por lo que no requieren un cierre explícito.

Como mi compañía descubrió recientemente, hay una muy buena razón para preferir cerrar-ellos-fusionar. Como han discutido otras respuestas, en fusionar-luego-cerrar terminas con una "cabeza topológica" extra, mientras que en la fusión cercana-cerrada no dejas esta cabeza extra detrás.

Resulta que estos cabezales adicionales se suman , y eventualmente pueden causar problemas en las operaciones de sincronización (donde Mercurial necesita negociar qué cabezas están en qué lado descubrir los conjuntos de cambios para empujar o tirar). A medida que crece la cantidad de cabezas topológicas que cuelgan, estas operaciones se hacen cada vez más grandes, hasta que finalmente comienzan a fallar . Afortunadamente, puede limpiarlos bastante fácilmente más adelante, pero probablemente sea mejor evitar el problema en primer lugar.

Esto no es una cuestión de gusto y hay una diferencia . En resumen, cierre la rama y luego fusione .

Lo que pasa es que los nombres de las ramificaciones de Mercurial son meramente "metadatos" para cada conjunto de cambios. Afecta los resultados de ciertos comandos como hg branches omite los cerrados, o hg push no permite la adición de un nuevo encabezado por rama de manera predeterminada. Pero de nuevo, está filtrando.

Internamente, Mercurial ve el repositorio como un gráfico de conjuntos de cambios, el DAG es específico. Y los encabezados topológicos de ese gráfico se usan para la implementación lógica, por ejemplo, mientras se comparan los repositorios locales y remotos durante la hg pull . Un mayor número de cabezas topológicas puede (levemente, pero aún) afectar el rendimiento. ¿Cómo afectan las ramas cerradas el rendimiento de Mercurial? . Además, cierto número de ellos puede causar 400 Bad Request de Mercurial en el servidor IIS - https://bitbucket.org/site/master/issue/8263/http-400-bad-request-error-when-pulling .

Cuando uno primero se fusiona y luego se cierra, la rama está cerca, está bien, y el ser humano no ve esa rama por defecto. Pero mercurial obtiene otra cabeza topológica. Mira abajo para una explicación visual. Por lo tanto, cerca primero.

Puede buscar aquí detalles sobre cómo llegamos a esta conclusión.