Home/ Questions/Q 6604421
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-25T19:09:14+00:00

I keep thinking I understand subrepos and how I can make them work for

  • 0

I keep thinking I understand subrepos and how I can make them work for my teams workflow, but clearly I don’t, because every time I try to implement some basic workflow, something doesn’t end up working right.

I’ve read pretty much everything there is to read about subrepos online, and I follow all of the trivial examples people post, but when I try to do something more complicated. Or maybe I do understand it perfectly well, and what I’m trying to do is just not something that works well.

Lets get the basics out of the way. Lets say I have a remote “blessed” collection of repos.

http://acme.com/BlessedRepos/ProjA
                            /LibA
                            /LibB

So I do a clone of /ProjA to C:\ProjA and clone /LibA to C:\ProjA\LibA and /LibB to C:\ProjA\LibB. I create my .hgsub file with

LibA = http://acme.com/BlessedRepos/LibA
LibB = http://acme.com/BlessedRepos/LibB

I commit everything. I can then push ProjA and all is well.

So now someone on my team can go clone /PrjoA to C:\dev\ProjA and it will bring down LibA and LibB too as subrepos. This person can easily push/pull from the “blessed repo” just like I can. So good so far.

Now, I say: Ok, ProjA Team, stop pushing to the blessed repo, that’s for me to do after reviewing your work. Starting now, I want you all to push your changes to the ProjA dev and ProjA QA remote repos located at:

http://acme.com/Dev/ProjA
http://acme.com/QA/ProjA

This is where we stop. Trying to push to http://acme.com/Dev/ProjA will only push /ProjA, while /ProjA/LibA and /ProjA/LibB get pushed back to their original location in the blessed repo and not the desired location of http://acme.com/Dev/ProjA.

Now, I could have setup my .hgsub file as LibA = ../LibA. This would work initially, but if I were to do a clone of ProjA from the blessed repo, it fails to get LibA or LibB, I believe because it’s expecting to find local repos LibA and LibB as siblings to the ProjA repo I’m cloning. What I mean is if I’m cloning to http://acme.com/BlessedRepos/ProjA to C:\Test\ProjA it will fail because it expect to find an existing repo at C:\Test\LibA.

I could also have setup my hgsub as LibA = LibA. But doing this fails when you try to push to the blessed repo as LibA is not a nested of ProjA in the blessed space. I could create them, but then I’m never pushing back to http://acme.com/BlessedRepos/LibA, only to http://acme.com/BlessedRepos/ProjA/LibA, and then it seems that has defeated the purpose of the subrepo to begin with.

I’m pretty sure my first method could work if I also had some script that I would run that would go through and change out all the values in the .hgsub file from “blessed” remote locations to the “dev” and “QA” locations, but this seems less than ideal.

So. If there is anyone out there that really groks this stuff, could you either explain to me where I’ve gone wrong, or how I could achieve my original workflow using subrepos, or maybe just confirm that I am going after something that isn’t really suited for subrepos. If it helps to understand the situation, we have probably something like 15-20 “products/solutions” and 50 “shared” projects. Any of the 15-20 products can make use of N number of the 50 shared projects in it’s solution.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The key part you are missing is that you can expose the LibA and LibB repositories multiple times on the server without having multiple copies on the server. Please see my answer to another question about subrepos for the details.

    Also, just come talk to us at #mercurial if you have problems like that — that’s much better than writing long posts on StackOverflow since that’s not where the Mercurial community is anyway. You can also use the mailinglists we have.

    • 0