Problem using subrepos

Mads Kiilerich mads at
Thu Jun 2 18:00:17 CDT 2011

Eric M Lafrance wrote, On 06/02/2011 06:25 PM:
> "/(Ok, other mappings than trivial relative x=x mappings can work just
> fine if Mercurial is used in a 100% centralized model without any
> distributed cloning or pulling - but then why use Mercurial?)/"
> We will need to have a centralized repository where the updated source 
> code is available so that we can compile it. We don't want to have 
> each and every developper to compile bits and pieces here and there, 
> as it can add complexity to our releases management. Even distributed 
> projects have that kind of "centralized" place where code gets 
> compiled in the end, if my understanding is correct. We currently have 
> a old archaic and out-dated SCM, and we wish to change for something 
> else that works better. Everything I read about distributed system 
> confirmed to me that it is possible to "emulate" a centralized way of 
> working, that it can do just about anything. And so far, the best 
> choice I though we had was to use Mercurial.

Yes, Mercurial works fine that way. Subrepositories with trivial 
mappings also generally works fine - the subrepositories will follow the 
outer repositories when you clone, push and pull. (Subrepositories do 
however have some rough edges.)

Non non-trivial mappings works fine if you have a 100% centralized model 
where all the users only interact with one central server. Local cloning 
of clones and pushing/pulling between clones will be hard with 
non-trivial mappings.

> I'm interested to know how you would suggest we implement the usage of 
> Mercurial in my business with regards to how we can link projects with 
> shared libraries. It is my first experience with a distributed SCM 
> (I'm working with a decendent of CVS at the moment), and there is most 
> probably some things I don't quite get. So, I'm all ears for any 
> implementation suggestions/hints you have for me. We haven't yet 
> started the deployment of Mercurial, so now is the best time to adapt 
> our strategy I think.

I suggest you use trivial mappings. That means that the "same" shared 
library will have to appear in several places on your central server 
(just like it is cloned to several developer PCs and each of them might 
have many clones of the same library). The sharing of the shared library 
must be handled somehow - there are at least two options:

I think a good solution in many cases is to let the owner or release 
manager propagate changes between the different instances on the central 
server. There is often a need for some kind of control and qa of what is 
shared anyway.

Another solution is to let the server make one shared repository appear 
in many locations. That could be with symlinks, bind mounts, URL 
rewriting, or perhaps with the "share" extension.

In all cases: Remember that new revisions in a subrepo won't be used 
until they are referenced from .hgsubstate.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Mercurial mailing list