Tracking in-house libraries in subrepositories

Question

We are developing an in-house framework that several projects are going to use. The idea is to have the entire framework tracked as a mercurial subrepository of each project's repository. This resulted in the following subrepo tree (see thin-shell repository):

ProjectMaster/
    Project/
    CommonLib/
    FrameworkMaster/
        Framework/
        CommonLib/

• Does this make any sense to you? Is there a better/simpler way to handle these dependencies which doesn't involve subrepositories?
• Specifically, does it make sense to have both CommonLib subrepositories?
• If not, would it make sense for Project to use FrameworkMaster/CommonLib? This could get messy if the dependencies were more complicated.
• Where would you open feature branches? On the master? Only in the relevant subrepository?
  • If you don't have feature branches on the master, every time you clone the repository you end up getting the subrepo state of the last commit, which may put any subrepo in any random feature branch. Very confusing.
  • If you have feature branches on the master, you still need a feature branch in at least one subrepo to avoid having unnamed heads there.

In general, this solution sounds difficult to work with. Any suggestions?

Answer 1

As per description in the thin-shell repository documentation:

For a thin-shell repository, all repositories containing 'real' code 
have no subrepositories of their own (ie. they are leaf nodes). They can 
thus be treated as completely ordinary repositories and a developer can 
largely ignore the additional complexities of subrepositories. Work can 
continue in these repositories even if their siblings become unavailable. 

The resulting structure you have described has nested subrepositories that contains 'real' code and hence its not the recommended way. As per mercurial documentation, the recommended structure would be as following (I don't know if /FrameworkMaster/ was included as just place holder for nested subrepositories or it also have 'real' code. If /FrameworkMaster/ also has 'real' code then it should also be included in following as sibling leaf node):

ProjectMaster/
    Project/
    Framework/
    CommonLib/ 

So, to answer your questions:

• Does this make any sense to you? Is there a better/simpler way to handle these dependencies which doesn't involve subrepositories?

The better/simpler way would be to use the thin-shell repository to simplify the complex dependencies.

• Specifically, does it make sense to have both CommonLib subrepositories?

If both Project and Framework are depending on same version or branch of CommonLib then it doesn't make sense to have it at both places. But if for some legacy reasons Project and Framework are requiring different version or branch of CommonLib then it does make sense to have CommonLib at both places.

• Where would you open feature branches? On the master? Only in the relevant subrepository?

Not sure here what you mean by feature branches. Did you meant to say 'future' here?