Controle de versão (hg): um diretório pode ser “sincronizado” com diferentes repositórios?

Question

Eu tenho um diretório para meus arquivos de trabalho que está sob controle de versão (Mercurial):

~ / myfiles

Em um subcaminho, eu tenho um diretório com pacotes do Emacs para minha configuração no modo de organização:

~ / myfiles / org-mode

Como eu disse, todo o caminho está sob controle de versão e, portanto, "sincronizado" com um repositório Hg. A fonte original do subdiretório org-mode também é um repositório (git) na Internet ( link ).

Por isso, seria bom poder extrair novas versões deste diretório diretamente do repositório oficial do modo de org e então enviá-las ao meu repositório pessoal para ter sempre a versão que funciona com a configuração do Emacs.

Para um programador, essa pode ser uma pergunta muito fácil - como não sou programador, não sei como lidar com isso, mas suponho que seja um problema comum.

Claro que eu poderia salvar o diretório do modo de organização localmente em outro caminho e mantê-lo fora do meu controle de versão, mas eu não seria capaz de restaurar a configuração completa de trabalho em um determinado momento com facilidade.

    

Answer 1

Usar tanto hg como git , na mesma árvore, não traz nenhum conflito inerente; como esses programas foram desenvolvidos independentemente, é lógico que eles não interfiram uns com os outros.

No entanto, e neste caso, hg sobrepõe-se a git (outra forma de ver é que o repositório git depende do estrutura de diretórios subjacente hg ). Como tal, considere o seguinte exemplo, onde você já tem o org-mode clonado e há um patch esperando para ser retirado do repositório online.

Isto é o que hg pode parecer antes de você puxar as alterações de git :

c:\myfiles> hg log -l 1
changeset:   123:da5f372c3901
tag:         tip
user:        John Doe <[email protected]>
date:        Fri Jun 13 12:00:00 2014 -0500
summary:     Some change in the work files

Você então puxa as mudanças para o org-mode de git . O que mais importa aqui, porém, é que a ação pull não imediatamente reflita para o repositório hg .

Você pode testar se os patches mais recentes do org-mode funcionam. Se eles não funcionarem corretamente, você deve executar hg revert --all , que irá restaurar a aparência do repositório no momento do último commit. Se eles funcionarem ou você não encontrar nenhum problema, você deve confirmar uma alteração em hg refletindo que você fez um conjunto de alterações no modo de organização .

c:\myfiles> hg com -m "Pulling changes in org-mode"

c:\myfiles> hg log -l 1
changeset:   124:da5f372c3901
tag:         tip
user:        John Doe <[email protected]>
date:        Fri Jun 13 12:01:00 2014 -0500
summary:     Pulling changes in org-mode

Se git armazena seus metadados em relação ao repositório sob a pasta org-mode (isto é, como hg faz com a pasta .hg no raiz do repositório), não deve haver um problema em reverter o commit sob hg (se por acaso você, após confirmar, achar que há um problema com o org-mode ):

c:\myfiles> hg rollback
rolling back last transaction

c:\myfiles> hg log -l 1
changeset:   123:da5f372c3901
tag:         tip
user:        John Doe <[email protected]>
date:        Fri Jun 13 12:01:00 2014 -0500
summary:     Some change in the work files

Além disso, conforme declarado em meus comentários, você pode fazer isso independentemente de qualquer software VCS executado. Se você tem:

c:\my_repo
c:\my_repond_repo

Não haveria nenhum problema, pois para trabalhar com cada repositório, você teria que trabalhar dentro do diretório onde está trabalhando.

^{1 - Eu adaptei alguns códigos daqui porque, como declarado, eu não tenho muita experiência no assunto}

    

Answer 2

Parece que você deseja que o modo de organização seja um subrepo . E parece que o git é suportado como sub-repo. A documentação é clara sobre o que fazer em seguida:

echo "http://orgmode.org/cgit.cgi/org-mode.git" >> .hgsub
hg add .hgsub
git clone http://orgmode.org/cgit.cgi/org-mode.git org-mode

Isso permite rastrear seus itens localmente e extrair alterações do orgmode quando estiverem disponíveis.

    

Answer 3

Seu código depende de um "ramo de fornecedores". Cada um tem seu repositório. Sem problemas. A maioria dos sistemas de controle de versão permite uma 'exportação' do código mais recente, ou seja, sem metadados. Se você cometer isso em seu próprio repositório, não haverá colisão. É improvável que você precise se comprometer com os dois repositórios. Mas se você precisar, você provavelmente pode resolver isso. Termo de pesquisa: 'ramo de fornecedor'