[PATCH] sburepo: change default path in hgrc of subrepo after cloning

Johannes Totz jtotz at imperial.ac.uk
Tue Feb 9 12:32:50 CST 2010


Saint Germain wrote:

> Hello,
>
> 2010/2/9 Johannes Totz <jtotz at imperial.ac.uk>:
>>> Apologies: with my previous patch
>>> (http://hg.intevation.org/mercurial/crew/rev/e1401c74572f) on subrepo
>>> default path, it seems that I've introduced a regression.
>>>
>>> Indeed when committing a new subrepo, its default path should be
>>> automatically set to the value referenced in .hgsub.
>>
>> I don't think that commit should modify a subrepo's hgrc. Only when
>> cloning a master-repo the new clone's hgrc should get a default-path,
>> that is both the cloned master-repo and the subrepos inside it.
>
> If no hgrc is present for the subrepo, the subrepo is not aware of
> where it comes from. So it's not possible to just 'hg pull' in the
> subrepo directory. Of course it's possible to 'hg pull' from the main
> repository which should recursively pull from all its subrepos.
>
> Previous to my patch, Mercurial behavior was to fill the subrepo
> default path when committing a new subrepo. 

Ah... I was not aware of this! I have never actually started off with a
"virgin" subrepo. I have always had stuff in them and just put a new
master-repo around to glue them together.
So that could explain some of our misunderstandings :)
Lets skip the bits about commit and focus on cloning only...

>>> My new patch solves the problem.
>>>
>>> However it raises one interesting issue. In case of a clone repository,
>>> we have a discrepancy between .hgsub and the default path.
>>>
>>> For instance, if we have in /tmp/main/.hgsub:
>>> nested = /tmp/nested
>>>
>>> We should have in /tmp/main/nested/.hg/hgrc:
>>> [default]
>>> path = /tmp/nested
>>
>> This should not get set automatically!
>
> I don't understand: you previously said "Only when cloning a
> master-repo the new clone's hgrc should get a default-path, that is
> both the cloned master-repo and the subrepos inside it".
> So in case of cloning a master (and so the subrepo), the hgrc of the
> master and the hgrc of the subrepo shall be set automatically ?

Yes, this is what happens for an "ordinary" repo. When cloning, the
clone gets a default-path that points to the original location.

> Or is this the value of the default path you are talking about ?
>
>>> If we clone main2 from main, we should have for
>>> /tmp/main2/nested/.hg/hgrc:
>>> [default]
>>> path = /tmp/main/nested
>>
>> It should be /tmp/nested because that is the path that would have been
>> used to clone it from (it's in .hgsub).
>
> That is the point I was discussing with 'sjl' and 'tonfa' on #mercurial IRC.
> If we have multiple cloning : A -> B -> C.
> Shall C reference B or A ?
> It seems that in 'mercurial spirit' a repository is the equal to all
> the others and is independant. So I think that C shall reference B
> instead of A.

Agree.

> And so in C subrepos, we reference B subrepos instead of A subrepos
> (the reasoning is valid for both absolute and relative reference).

Maybe not. What I'm not sure about is how cloning subrepos actually
works. See below.

> Otherwise if we have a long cloning chain : A -> B -> C -> D -> E, it
> is not guaranteed that E would have access to A.
> BUT I'm not here to impose my opinions (that's why I discussed it with
> 'sjl' and 'tonfa') and I'm not sure to understand correctly all the
> mercurial subtleties, so you are free to disagree !
>
>>> But what about /tmp/main2/.hgsub ?!??
>>> The most 'logical' thing would be to set it to:
>>> nested = /tmp/main/nested
>>
>> .hgsub should follow the existing behaviour, i.e. leave it as is. If
>> main/.hgsub says /tmp/nested then main2/.hgsub should be the same.
>>
>
> That would mean that the subrepo original address is propagated. That
> would introduce a different behavior in case we are using subrepos or
> not.

I might misunderstand how cloning subrepos actually works. What I
thought how it works is that on update hg consults .hgsub for a URL and
clones from there.
So if in .hgsub I have
  nested = http://my.server.com/repos/whatever
The new subrepo will be cloned from that URL, irrespective of the
current location of the master-repo and any existing working copies of
the subrepos.
If I have in .hgsub
  nested = nested
then the URL is relative to the current location of the master-repo. And
the URL that nested is cloned from could be something like
/home/code/master-repo/nested.

If the above is not how it works then forget about anything I said
earlier! (but I would still like to know how it works.)

So either http://my.server.com/repos/whatever or
/home/code/master-repo/nested should be the default-path for
/home/code/cloned-master-repo/nested because that is the path it was
cloned from.

> Let me explain with an example.
> Let's say that we have a simple repo 'A' with 3 sub-directories 1, 2
> and 3. In this situation if we have the cloning A -> B -> C, then C
> will be pulled from B as a default.

Yeah.

> Now we decide to break the simple repo in 3 subrepos 1, 2 and 3. In
> this situation if we have the cloning A -> B -> C, then it seems _for
> me_ that C should be pulled from B

Yeah.

> C1 should be pulled from B1, C2 from B2 and C3 from B3.

Depending on what .hgsub looks like. Only if its URLs are relative.

> If we want to keep .hgsub without modification, then C will be pulled
> from B, C1 will be pulled from A1, C2 from A2 and C3 from A3. It seems
> quite strange to me.

In this example, yes.
If .hgsub is modified with local paths that will break it for anyone
else. Because it references B's location that doesn't exist for any
other developer.

>>> But I'm not allowed to modify .hgsub because it is version controlled !
>>>
>>> What would be the correct behavior then ?
>>
>
> I hope that you understand what I wanted to explain. Again, it's just
> questions that I've asked myself while trying to correct some bugs on
> mercurial. Didn't want to break anything 

> or to step on any shoes...

No worries, not wearing any :)



More information about the Mercurial-devel mailing list