Problem using subrepos

Scott Palmer swpalmer at gmail.com
Thu Jun 2 11:26:41 CDT 2011


On 2011-06-02, at 9:25 AM, Mads Kiilerich wrote:

> 
> "Doctor, doctor, it hurts when I use subrepos with non-trivial mappings".
> "Well, then don't do that!"
> 
> (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?)
> 
> /Mads

I think it is important to find a solution other than trivial mappings for this.  There are times when you want a common library to be shared by otherwise unrelated modules, and while there are alternative solutions to this, the (potential) subrepo solution is intuitive.

E.g. Project A and B both want to use Library C, but it needs to be extended to meet their needs.  Both A and B will make a repo that pulls in C as a subrepo.  They will both simultaneously be working on changes that affect the library C and the project they are using it with.  Since C is a shared library they will obviously want to share the changes with each other to ensure they aren't duplicating effort or breaking each other's code.  There are many ways to do this, but if they do share a common repo to push/pull their changes it will at least make them aware that they aren't the only one working on C.

This is the solution that arises from using an absolute path to C in the .hgsub file.  It works okay most of the time.  But there are the usual benefits of the distributed model that they are missing out on.  They could realize some of those benfits if clones of their A+C and B+C repos could be made in the usual manner and those clones didn't unexpectedly push C directly back to the "central" server while pushing the unshared A or B project to it's natural parent repo.

This has been brought up in the past and I've seen a few interesting suggestions for allowing it to work, but I'm not sure if there is any consensus on a solution or desire to get it done by the core Mercurial dev team.

Scott



More information about the Mercurial mailing list