Problem using subrepos

[Mads Kiilerich]

Scott Palmer wrote, On 06/02/2011 06:26 PM:
> 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.

I have no doubt that you have valid use case, but I don't understand how 
you can be so sure up front that "trivial mappings" is the wrong 
solution. It (and subrepos in general) might be incomplete, but that's a 
different story.

> 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.

Well ... only if they watch what is going on in the other anonymous 
branches and update/merge with what the other team is doing and commits 
a new .hgsubstate.

> 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.

There is no consensus on what the solution should be, and the only thing 
that is known is that if we choose the wrong solution we will have to 
support it forever anyway.

It is however getting more and more clear to me that the only thing that 
is known for sure is where the subrepo should be "mounted" and what 
revision it should be updated to. The advantage of trivial mappings is 
that they don't say more than that, and .hgsubstate thus says it all. 
That is thus all that should be tracked in the outer repository.

Mercurial is a DVCS where clones can be cloned locally, and as this 
thread shows it is a valid expectation that this applies to repositories 
with subrepositories too. It follows from how subrepositories lives "in 
place" in both "source" and "target" repositories that this location 
also is the natural location to look for subrepositories. (Ok - trivial 
mappings also says that.)

Assuming there are cases where other source/target destinations for 
subrepositories must be used, it seems like they are more temporary and 
depends on time and location and policy: One of the clones (which 
however might be the central server) might have alternative locations 
for the subrepositories. One of the repositories might be an external 
repository that currently is hosted in one place which might be gone 
tomorrow (most projects should however probably use a local clone for 
all daily operations anyway). There might also be alternative (local) 
locations that should be used if possible before falling back to the 
more expensive default location.

All these non-trivial locations for subrepositories should thus live 
outside the repositories. Some could perhaps be stored in configuration, 
and some could perhaps be propagated with pushkeys.

(Note: Here I'm only referring to Mercurial subrepos. Git subrepos might 
be very similar, but Subversion repositories are different.)

/Mads