Houve algumas perguntas sobre dependências de sub-reporte de Hg no passado Aqu eAqu) mas as respostas aceitas parecem não resolver o problema para mi

Um projeto meu tem 4 dependências: A, B, C, D. D é dependente de A, B e C; e B e C dependem de A:

Eu quero usar os sub-repositórios Hg para armazená-los, para que eu possa acompanhar em qual versão cada um deles se baseia. Isso ocorre porque, enquanto estou usando A, B, C e D neste projeto,outros projetos exigirão apenas A e B. Portanto, B e C devem rastrear qual versão de A eles precisam independentemente de D. Ao mesmo tempo, em meu aplicativo, as versões de B e C referenciadas por uma determinada versão de D sempre devem usar a mesma versão de A que a referenciada pelo dada a versão do D (caso contrário, apenas cairá em tempo de execução). O que eu realmente quero é permitir que eles façam referência um ao outro como irmãos no mesmo diretório - ou seja, o .hgsub de D seria semelhante ao seguinte e os B e C pareceriam a primeira linha.

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

No entanto, isso não parece funcionar: eu posso ver o porquê (seria fácil dar às pessoas corda suficiente para se enforcarem), mas é uma pena, pois eu acho que é a solução mais limpa para minhas dependências. Li algumas sugestões de soluções que descreverei rapidamente e por que elas não funcionam para mim:

Include cópias como subdiretórios aninhados, referencie-os como sub-repositórios Hg. Isso gera a seguinte estrutura de diretórios (removi as cópias principais de A, B, C, B \ A, C \ A, pois posso aceitar fazer referência às cópias dentro de \ D):

project \ (todos os principais arquivos de projeto)project \ Dproject \ D \ Aproject \ D \ Bproject \ D \ B \ Aproject \ D \ Cproject \ D \ C \ A

Problemas com esta abordagem:

gora, tenho 3 cópias de A no disco, todas com modificações independentes que precisam ser sincronizadas e mescladas antes de passar para um repositório centra Preciso usar outros mecanismos para garantir que B, C e D estejam fazendo referência à mesma versão de A (por exemplo, D poderia usar a v1 enquanto D \ B poderia usar a v2)

A variação: use o acima, masespecifique o RHS do .hgsub para apontar para uma cópia na cópia pai (ou seja, B e C devem ter o. hgsub abaixo):

A = ..\A

Problemas com esta abordagem:

Ainda tenho três cópias no disco A primeira vez que clono B ou C, ele tenta extrair recursivamente a versão referenciada de A de ".. \ A", que pode não existir, provavelmente causando um erro. Se não existir, não dá idéia de onde o repositório deve ser encontradQuando pressiono recursivamente as alterações, as alterações em D \ B \ A não entram no repositório central compartilhado; eles são empurrados para D \ A. Portanto, se eu pressionar duas vezes seguidas, posso garantir que todas as alterações serão propagadas corretamente, mas isso é uma fars Da mesma forma, se eu fizer um puxão recursivo (manual), tenho que acertar o pedido para obter as alterações mais recentes (por exemplo, puxar D \ A antes de puxar D \ B \ A)

Usar symlinks para apontar a pasta \ D \ B \ A para D \ A etc.

Problemas com esta abordagem:

@symlinks não pode ser codificado no próprio repositório Hg, portanto, toda vez que um membro da equipe clona o repositório, eles precisam manualmente / com um script para recriar os links simbólicos. Isso pode ser aceitável, mas eu prefiro uma solução melhor. Além disso (preferência pessoal), acho os links simbólicos muito pouco intuitivo

Essas são as melhores soluções disponíveis? Existe uma boa razão para o meu .hgsub inicial (veja o topo) ser um sonho, ou existe uma maneira de solicitar / implementar essa alteração?

ATUALIZAD para explicar melhor o uso mais amplo de A, B, C, D