mercurial - Hg sub-repository dependencies -

there have been couple of questions hg sub-repo dependencies in past (here , here) accepted answers don't seem address problem me.

a project of mine has 4 dependencies: a, b, c, d. d dependent on a, b , c; , b , c dependent on a:

i want use hg sub-repositories store them can track version of each rely on. because, while using a,b,c , d in project, other projects require , b. therefore b , c must track version of need independently of d. @ same time, in application versions of b , c referenced given version of d must use same version of referenced given version of d (otherwise fall on @ runtime). want allow them reference each other siblings in same directory - i.e. d's .hgsub following, , b , c's first line.

..\a = https:(central kiln repo)\a ..\b = https:(central kiln repo)\b ..\c = https:(central kiln repo)\c 

however doesn't seem work: can see why (it'd easy give people enough rope hang with) shame think neatest solution dependencies. i've read few suggested solutions i'll outline , why don't work me:

1. include copies nested sub-directories, reference these hg sub-repositories. yields following directory structure (i've removed primary copies of a, b, c, b\a, c\a can accept referencing copies inside \d instead):

   • project\ (all main project files)
   • project\d
   • project\d\a
   • project\d\b
   • project\d\b\a
   • project\d\c
   • project\d\c\a

   problems approach:

   • i have 3 copies of on disk, of have independent modifications must synced , merged before pushing central repo.
   • i have use other mechanisms ensure b, c , d referencing same version of (e.g. d use v1 while d\b use v2)

2. a variation: use above specify rhs of .hgsub point copy in parent copy (i.e. b , c should have .hgsub below):

   a = ..\a 

   problems approach:

   • i still have 3 copies on disk
   • the first time clone b or c attempt recursively pull referenced version of "..\a", may not exist, presumably causing error. if doesn't exist gives no clue repo should found.
   • when recursive push of changes, changes in d\b\a not go shared central repo; pushed d\a instead. if push twice in row can guarantee changes have propagated correctly, quite fudge.
   • similarly if (manual) recursive pull, have order right latest changes (i.e. pull d\a before pull d\b\a)

3. use symlinks point folder \d\b\a d\a etc.

   problems approach:

   • symlinks cannot encoded in hg repo every time team member clones repo, have manually/with script re-create symlinks. may acceptable i'd prefer better solution. (personal preference) find symlinks highly unintuitive.

are these best available solutions? there reason why initial .hgsub (see top) pipe-dream, or there way can request/implement change?

updated better explain wider usage of a,b,c,d

instead of trying manage dependencies via mercurial (or scm matter), try using dependency management tool instead, such apache ivy.

using ivy based approach, don't have sub-repos, have projects a, b, c , d. produces artifact (e.g. .jar, .so or .dll, etc), published artifact repository (basically place keep build artefacts) version. projects b , c can depend on specific version of (controlled via ivy.xml file in each project) ivy retrieve artifact repository. projects b , c produce artefacts published repository. project d depends on b , c , ivy can told retrieve dependencies transitively, means artifacts b, c , (because depend on a).

a similar approach can used apache maven , gradle (the later uses ivy)

the main advantages that:

• it makes clear versions of each component project using (sometimes people forget check .hgsub, don't know working subrepos),
• it makes impossible change dependant project (as working artifacts, not code)
• and saves having rebuild dependent projects , being unsure of version using.
• saves having multiple redundant copies of projects used other projects.

edit: similar answer different spin @ best practices project feature sub-modules mercurial , eclipse?