Se você tiver a opção, vá com uma ferramenta dedicada em vez de usar o SCM para isso. Eu tenho escrito sobre isso em SO , mas o argumento se resume ao acoplamento, em particular acoplamento muito strong O desenvolvimento flexível de software tem tudo a ver com evitar acoplamentos apertados, a menos que seja realmente necessário e ambos os subrepositórios Mercurial e os submódulos Git introduzam um acoplamento muito strong.
Além disso, os subrepos / submódulos introduzem complexidade extra no fluxo de trabalho diário. Se as pessoas já estão familiarizadas com o SCM, isso pode ser aceitável. Mas eu vi muitas organizações onde eles tentam introduzir os sub-posicionamentos Mercurial e ao mesmo tempo - eu considero isso um erro, uma vez que isso faz tudo parecer mais complicado.
O wiki do Mercurial tem um conjunto de recomendações sobre como os sub-interesses devem ser usados. Estes incluem o uso de um repositório thin shell. Isso evita o acoplamento dos componentes juntos. Você pode trabalhar em qualquer subrepo conforme necessário e pressionar / puxar para atualizá-los. De vez em quando, alguém (talvez um engenheiro de desenvolvimento, talvez um servidor de integração contínua) testará novas configurações dos componentes. Se eles passarem nos testes, um novo commit será feito no repositório do shell para que as pessoas tenham uma nova base para usar em seu trabalho.