Podskładniki Mercurial - zarządzanie bardziej złożonymi hierarchiami zależności

Question

Mam projekt główny, który używa dość standardowego podejścia do drzewa źródłowego + podskładników mercurial.

Master 
\lib - compiled binaries - things like log4net, AutoFac, etc 
\source - VS solution, one folder per project, etc 
\tools - stuff used during the build process 

\source\contrib - contains any subrepos like so: 

\source\contrib\Sub1 
\source\contrib\Sub2 

Master\.hgsub contains something like 
source\contrib\Sub1 = https://myserver.com/Sub1 

Niedawno ustalono, że Sub2 potrzebuje kodu z Sub1, a więc muszę dostosować do tej nowej struktury zależności.

Problem oczywiście polega na tym, że jeśli zastosuję to samo podejście, co powyżej i dodaję Sub1 jako subrepos Sub2, kończę z tą brzydką sytuacją.

\source\contrib\Sub2\source\contrib\Sub1 

Mistrz ma teraz 2 niezależne kopie Sub1!

Więc wiem, że powinienem używać względnych ścieżek podczas odwoływania się do podobiektów (RHS z =) - ale to nie pomoże mi w moim scenariuszu tutaj, jak rozumiem. Nie sądzę, że istnieje sposób, aby LHS na żywo na zewnątrz z repozytorium Master, które I myśleć jest to, czego naprawdę potrzebuję tutaj.

Mam kilka pomysłów, jak to naprawić, ale żadna nie pasuje do mnie i zakładam, że musi być lepszy sposób. Moje idealne rozwiązanie pozwala mi dzielić się tym samym sub-repo w ramach wielu projektów bez płacenia kary za posiadanie wielu kopii. Wydaje się, że po prostu marnotrawstwem i nieefektywne w moim scenariuszu tutaj (plus, chciałbym, aby wszystkie projekty, które mają zależność Sub1 korzystać z tego samego hg rewizji, zamiast revisioned jest niezależnie)

1. Usuń Sub1 jako podskładniki Master i zmienić dowolne ścieżki względne w rozwiązaniu Master, aby odnieść się do podwójnie zagnieżdżonego Sub1. Nie tylko ta struktura ścieżki jest ohydna, ale jeśli dodasz Sub3 do mastera, który ma zależność od Sub1, nadal mam 2 kopie Sub1.

2. Skompiluj kopię Sub1 i po prostu odepchnij ją w katalogu \ lib. Sub1 wciąż przechodzi pewne zmiany, a ja wolałbym budować przeciwko wersjom źródłowym. Nie chcę płacić podatku ciągłego kopiowania w nowych plikach binarnych do drzewa źródłowego przez cały czas (i wzdęcia drzewa).

3. W jakiś sposób zerwać zależność Sub2 od Sub1. W oparciu o architekturę repozytoriów prawdopodobnie tak się nie stanie. Sub1 zawiera bardzo ogólny kod biblioteki współdzielonej. Sub2 zawiera kontrakt/interfejs/typy usług WCF, które są potrzebne w dwóch bardzo osobnych projektach - SDK klienta i wdrożenie serwera. W tym momencie rozsądne będzie oddzielenie tych repozytoriów.

Może myślę o tym źle ... a może nie jestem świadomy jakiejś sztuczki hg.

Każda pomoc jest doceniana.

Answer 1

Powiedziałbym, zapomnij o sprawdzaniu w plikach binarnych, które po prostu prowadzi do nadpisania repozytorium. IMO, żadne dane wyjściowe z kompilacji nie powinny być przechowywane w repozytorium źródłowym.

Co powiesz na uczenie Sub2, że spodziewasz się znaleźć Sub1 na ../Sub1? Następnie, jeśli zauważysz, że musisz pracować nad Sub2 niezależnie od Sub1, stwórz repozytorium "Sub2_standalone", które przyciągnie Sub1 i Sub2 jako sub-repos.

Tak więc, gdy pracuje się na wszystko, można uzyskać:

Master/ 
Master/source/contrib/Sub1 
Master/source/contrib/Sub2 

ale kiedy tylko działa na sub2:

Sub2_standalone/ 
Sub2_standalone/Sub2 
Sub2_standalone/Sub1 

Answer 2

Jeśli trzeba, że ​​struktura zagnieżdżona, można użyć dowiązania dla Sub1 poniżej Sub2, aby zapewnić, że obie wersje Sub1 są zawsze w tej samej wersji. Wtedy faktycznie masz tylko jedną wersję Sub1, która wydaje się być tym, czego chcesz.

na GNU/Linux wouly to być prosty ln -s source/contrib/Sub1 source/contrib/Sub2/source/contrib/Sub1