Mercurial subrepositories - managing more complex dependency hierarchies

Question

I have a master project that's using a fairly standard source tree approach + mercurial subrepositories.

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

Now, it was recently determined that Sub2 needs some code from Sub1, and hence I have to adjust for this new dependency structure.

The problem of course is that if I follow the same approach as above and add Sub1 as a subrepos of Sub2, I end up with this ugly situation.

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

Master now has 2 independent copies of Sub1!

So I know that I should be using relative paths when referencing subrepos (the RHS of the =) -- but that won't help out my scenario here as I understand it. I don't think there's any way to make the LHS live outside of the Master repository, which I think is what I really need here.

I have a couple of ideas on how to fix this, but none sits right with me, and I assume there has to be a better way. My ideal solution allows me to share the same sub-repo amongst multiple projects w/out paying the penalty of having multiple copies around. That just seems wasteful and inefficient in my scenario here (plus, I'd like to have all projects that have a dependency on Sub1 to use the same hg revision, rather than being revisioned independently)

1. Remove Sub1 as a subrepos of Master, and change any relative paths in the Master solution to reference the doubly nested Sub1. Not only is this path structure hideous, but if add a Sub3 to master that has a dependency on Sub1, I still have 2 copies of Sub1.

2. Compile a copy of Sub1 and just chuck it in the \lib directory. Sub1 is still undergoing some churn, and I'd rather build against the source versions. I don't want to pay the tax of constantly copying in new binaries to the source tree all the time (and bloating the tree).

3. Somehow break the dependency of Sub2 on Sub1. Based on the architecture of the repositories, this is probably not going to happen. Sub1 contains some very general purpose shared library code. Sub2 contains WCF service contract / interface / types that is needed in two very separate projects -- a client SDK and server implementation. At this point in time, it makes sense to keep these repositories separate.

Maybe I'm thinking about this wrong... or maybe I'm unaware of some hg trick.

Any help is appreciated.

Answer 1

I'd say, forget about checking in binaries, that just leads to repository bloat. IMO, any output from a build should not be stored in the source repository.

How about teaching Sub2 to expect to find Sub1 at ../Sub1? Then, if you find you need to work on Sub2 independently of Sub1, create a "Sub2_standalone" repo, that pull in Sub1 and Sub2 as sub-repos.

So, when working on everything, you'd get:

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

But when just working on Sub2:

Sub2_standalone/
Sub2_standalone/Sub2
Sub2_standalone/Sub1