¿Puedo enviar cambios a múltiples subrepos mercuriales a una nueva rama con nombre?

Question

Tengo un repositorio mercurial con múltiples repositorios dentro de él. El repositorio tiene una solución de estudio visual que contiene proyectos en el repositorio y el subrepositorio.

Supongamos que quiero implementar una nueva característica que requerirá cambios en el proyecto principal en el repositorio y cambios en uno de sus proyectos de dependencia en la solución (digamos, agregando una nueva interfaz compartida en la dependencia y una implementación de la interfaz en el proyecto principal).

Luego deseo confirmar los cambios, pero a una nueva rama con nombre ya que está sin terminar y se fusionará más tarde. Usando tortoiseHg comprometo los cambios en el repositorio, especificando una nueva rama para crear. El commit a su vez confirma los cambios del sub repo, pero en mis pruebas no crea una nueva rama en su repositorio, sino que simplemente agrega el conjunto de cambios a la rama actual.

Puedo realizar el compromiso con el repositorio secundario explícitamente y especificar el nombre de la sucursal en ese momento, pero esperaba una forma de enviar todo el conjunto de cambios en repositorios a nuevas sucursales en cada repositorio de una sola vez para que mi flujo de trabajo limpiador. es posible?

Answer 1

Primero comprometa el sub-repo y cree allí una rama con nombre.

Posteriormente, la confirmación principal debe seguir comprometiéndose con ese sub-repositorio en la misma rama que antes.

Primero debe pensar en los dos repositorios como separados, completamente separados. En otras palabras, haces algo en un repositorio y lo comprometes. Luego haces algo en el otro repositorio y lo comprometes.

La relación que tienen los dos repositorios es que el repositorio principal almacena un archivo, el archivo .hgsubstate, que contiene el hash del padre de la carpeta de trabajo de cada sub-repositorio.

En otras palabras, el sub-repositorio no tiene conocimiento en sí mismo de que sea parte de una imagen más grande. Sin embargo, el repositorio principal conoce la revisión actual desprotegida en ese sub-repositorio. Este conocimiento se confirma en el repositorio como parte de las confirmaciones normales.

Esto significa que si hace algo en el sub-repositorio, confirme eso, el sub-repositorio está ahora en una nueva revisión. Cuando más tarde se compromete en el repositorio principal, el hash de esa nueva revisión en el sub-repositorio se actualiza en el archivo .hgsubstate y luego se confirma.

El propósito de esto es, por supuesto, que si actualiza a una revisión anterior en el repositorio principal, una vieja copia del archivo .hgsubstate también se lleva a la carpeta de trabajo y luego se actualiza el sub-repositorio a esa revisión, que tiene el efecto de volver el reloj a cómo se veía el sub-repositorio cuando esas revisiones estaban en juego.

Además, los comandos en el repositorio principal a veces también funcionan en los sub-repositorios. Si inserta en el repositorio principal, también se presionan los sub-repositorios para garantizar que otros que clonen su repositorio principal también puedan confiar en poder clonar el contenido apropiado para el sub-repositorio.

Para responder a su pregunta en los comentarios.

Si crea una sucursal en el sub-repositorio, con nombre o no, continuará confirmando nuevos conjuntos de cambios en esa rama. En algún momento debe fusionar, y necesita fusionarse en el sub-repositorio así como también en el repositorio principal.

Primero se fusionaría en el sub-repositorio. Esto termina con una confirmación, lo que significa que el sub-repositorio está ahora en el conjunto de cambios que cometió la fusión. Luego se fusiona en el repositorio principal y la confirmación, que almacena ese conocimiento, que conjunto de cambios en el repositorio secundario que está en uso en este momento.

Así que sí, necesita fusionarse en ambas también, en un momento posterior.