Ha habido un par de preguntas sobre las dependencias de sub-repositorio de Hg en el pasado aqu yaqu) pero las respuestas aceptadas no parecen resolver el problema para mí.

Un proyecto mío tiene 4 dependencias: A, B, C, D. D depende de A, B y C; y B y C dependen de A:

Quiero utilizar los sub-repositorios Hg para almacenarlos y poder seguir la versión de cada uno de ellos. Esto se debe a que, mientras estoy usando A, B, C y D en este proyecto,otros proyectos requerirán solo A y B. Por lo tanto, B y C deben rastrear qué versión de A necesitan independientemente de D. Al mismo tiempo, en mi aplicación, las versiones de B y C a las que hace referencia una versión dada de D siempre deben usar la misma versión de A que la referenciada por el versión dada de D (de lo contrario, simplemente se caerá en tiempo de ejecución). Lo que realmente quiero es permitirles que se hagan referencia entre ellos como hermanos en el mismo directorio, es decir, el .hgsub de D se vería de la siguiente manera, y B y C se verían como la primera línea.

..\A = https:(central kiln repo)\A
..\B = https:(central kiln repo)\B
..\C = https:(central kiln repo)\C

Sin embargo, esto no parece funcionar: puedo ver por qué (sería fácil darle a las personas suficiente cuerda para ahorcarse), pero es una pena, ya que creo que es la mejor solución para mis dependencias. He leído algunas soluciones sugeridas que resumiré rápidamente y por qué no funcionan para mí:

Incluya copias como subdirectorios anidados, haga referencia a estos como sub-repositorios Hg. Esto produce la siguiente estructura de directorios (he eliminado las copias principales de A, B, C, B \ A, C \ A, ya que puedo aceptar hacer referencia a las copias dentro de \ D):

project \ (todos los archivos principales del proyecto)proyecto \ Dproyecto \ D \ Aproyecto \ D \ Bproyecto \ D \ B \ Aproyecto \ D \ Cproyecto \ D \ C \ A

Problemas con este enfoque:

Ahora tengo 3 copias de A en el disco, todas las cuales podrían tener modificaciones independientes que deben sincronizarse y fusionarse antes de pasar a un repositorio central. Tengo que usar otros mecanismos para asegurar que B, C y D hagan referencia a la misma versión de A (por ejemplo, D podría usar v1 mientras que D \ B podría usar v2)

Una variación: use lo anterior pero especifique el RHS del .hgsub para apuntar a una copia en la copia principal (es decir, B y C deben tener el .hgsub a continuación):

A = ..\A

Problemas con este enfoque:

Todavía tengo tres copias en el discoLa primera vez que clono B o C, intentará extraer de forma recursiva la versión de A referenciada de ".. \ A", que puede no existir, presumiblemente causando un error. Si no existe, no da idea de dónde se debe encontrar el repositorio.Cuando hago un empuje recursivo de cambios, los cambios en D \ B \ A no entran en el repositorio central compartido; simplemente son empujados a D \ A en su lugar. Entonces, si presiono dos veces seguidas, puedo garantizar que todos los cambios se habrán propagado correctamente, pero esto es una falsificación.e manera similar, si hago una extracción recursiva (manual), tengo que obtener el orden correcto para obtener los últimos cambios (es decir, extraer D \ A antes de extraer D \ B \ A)

Utilizar enlaces simbólicos para señalar la carpeta \ D \ B \ A a D \ A, etc.

Problemas con este enfoque:

symlinks no se pueden codificar en el repositorio de Hg, por lo que cada vez que un miembro del equipo clona el repositorio, debe volver a crear los enlaces simbólicos manualmente / con un script. Esto puede ser aceptable, pero preferiría una mejor solución. También (preferencia personal) encuentro los enlaces simbólicos muy poco intuitivos.

¿Son estas las mejores soluciones disponibles? ¿Hay una buena razón por la cual mi .hgsub inicial (ver arriba) es un sueño imposible, o hay alguna forma de solicitar / implementar este cambio?

ACTUALIZAD para explicar mejor el uso más amplio de A, B, C, D