A case for subrepos with absolute URLs

[Martin Geisler]

Angel Ezquerra <angel.ezquerra at gmail.com> writes:

> On Mon, Dec 12, 2011 at 7:12 AM, Arne Babenhauserheide <arne_bab at web.de> wrote:
>>
>> So maybe a subrepo should always be treated as trivial path, except
>> if that path does not provide the required changesets for the
>> substate.
>>
>> And in that case, we need some fallback-mechanism anyway. And that
>> could be the second part of the subrepo definition. It would change
>> the .hgsub definition to:
>>
>> subrepo = <fallback>
>
> I really like this idea of making the path in the .hgsub file a
> fallback or a "source of last resort" for subrepos.

Me too -- I've suggested it in the past, even with a patch:

  http://mercurial.markmail.org/thread/fwwd2mh34ejrnzki

Back then, Mads came up with a lot of questions and ultimately said that
he would not support my quest for making the .hgsub path a fallback URL.


Personally, I don't think it matters where we obtain a subrepo from. All
that matters is that we get a subrepo that has the correct changeset
hash. The cryptographic nature of SHA-1 guarantees that we can trust the
repo if the hash matches.

> If mercurial always tried (or could be configured to always try) to
> use the simple relative path first when pulling subrepos, and only
> tried to pull from the path configured in the .hgsub path if that
> failed, then many of the issues with using absolute paths would simply
> go away. They would go away because mercurial would always use
> relative paths by default, and it would only use absolute paths in
> those cases where it makes sense.
>
> For example, if this was done, creating local clones of repos using
> subrepos with absolute paths would be much faster and not require
> network access in most cases.

That's both an important optimization and a solution to the case where
an upstream repo disappears, rendering the absolute path unavailable. As
far as I can see, the subpath remappings used by, e.g., Lantiq would
then be unnecessary in most cases.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/