Path expansion in the .hgsub file

[JonnyDee]

Hi Martin,

> > If one sees these mappings as a way for providing alternate URLs why
> > not write:
>
> >    [paths]
> >    foo =http://server/path/to/repo
> >    foo = ssh://hg@server/path/to/repo
>
> > Or, if using the same key would override previous mappings
>
> >    [paths]
> >    foo.1 =http://server/path/to/repo
> >    foo.2 = ssh://hg@server/path/to/repo
>
> > and simply use 'foo' as key for the sub-repo reference in .hgsub.
>
> Yes, that is our usual scheme for grouping keys inside a section since
> later keys override earlier ones.
>
> With this suggestion, you want a .hgsub containing
>
>   some/path = foo
>
> to try the foo.1 location first then the foo.2 location?

Yes, exactly. And to be more concrete -- the order is not determined
by the number '1' or '2' but by the order within the file. In fact,
instead of numbers other ids should by possible. For instance,
'foo.bitbucket' or 'foo.google'.

> > I see the problem that this would require some logic which knows about
> > the <key>.<alternate-id> (like foo.1) convention. And there might by
> > backward compatibility problems for those who already used the '.'
> > char within keys. On the other hand, if it were allowed to reference a
> > concrete alternate (like foo.2) within the .hgsub, too, then there
> > wouldn't be such backward compatibility problem.
>
> If we go with the normal [paths] section, then we can run into changes
> in behavior when we begin remapping source locations. If we use another
> name for the section, then we are safe.

Yes, you're right. And it seems like Matt will favor the 'another name
for the section' solution...?

> >> Matt proposed an [alternates] section for this where the alternate
> >> URLs could be listed somehow.
>
> > Maybe one could use this new [alternates] section to list alternate
> > 'foo' mappings using the <key>.<alternate-id> pattern.
>
> >> I think this goes in a slightly different direction. The simple
> >> remapping feature can be used for situations where you already happen
> >> to have a local version of the subrepos (this was suggested in
> >> Issue1962) or when you know the old server is gone and wont return
> >> again.
>
> > The problem with old servers that are gone was the reason why started
> > the initial thread. So I think the direction is still the same.
>
> >> If you know the server is gone, then you don't want to wait until a
> >> connection attempt fails before contacting the new server. That suggests
> >> the alternatives should at least be tried first.
>
> > But there might be several alternates that are already gone, too. Or
> > these alternates could just be mirrors that Mercurial can contact if
> > the main location is not available at the moment.
>
> I guess people will update the alternatives listed in the .hgsub file as
> old ones disappear. That way the project can define a suitable default
> set of clone locations.

Yes, I would also expect that.

> My current patch looks like this -- feel free to try it out and see if
> it's useful for you:
> [...]

Thanks, I'll try it out. :)

Cheers,
Jonny