subrepo: what about making subrepo URLs configurable

[Kyle Altendorf]

On Thu, Feb 18, 2010 at 11:02, Brendan Cully <brendan at kublai.com> wrote:
> On Thursday, 18 February 2010 at 10:51, Kyle Altendorf wrote:
>> On Thu, Feb 18, 2010 at 09:58, Steve Losh <steve at stevelosh.com> wrote:
>> > Still, I think this should be *possible*, which would mean the URL does need to be version controlled.
>>
>> I believe it means that something that selects the appropriate
>> repository needs to be versioned.  I believe that this something
>> should absolutely NOT be a URL since URLs are far from immutable.
>> Anyways, isn't this functionality what I addressed in the second
>> section of my message included below?  Why would being a sub-repo
>> suddenly mean that the remote copy of that repository will never move?
>>  Hg certainly doesn't assume that for a 'normal' repo.
>>
>> -kyle
>
> One hack I can think of is to use [paths] to override the subrepo
> URLs:
>
> .hgsub
> src/libs/foo = http://oldserver/foo
>
> [paths]
> http://oldserver/foo = http://newserver/bar
>
> This keeps the versioning properties we have now, but lets you fix URL
> changes at the client. It doesn't let you retroactively fix old URLs
> centrally -- that would probably need some kind of tags-like override
> protocol -- but it's simple and should help.
>
> If it's confusing to put that in [paths], we could create a new
> subsection for it.

Just to clarify, are you saying this can be done at present or
proposing it as a solution?  Either way I agree it's a hack unless you
use it like:

.hgsub
src/libs/foo = foo

[paths]
foo = http://newserver/bar

or something similar.  In which case I think it's pretty close to
Jonny's original proposal except for storing the URL in the [paths]
section rather than the [subrepos] section.

Just to throw another use case out there, what about when you want to
use a personal (but still 'remote') copy of a subrepo because you are
hacking on it as well but not making the changes directly in your
local subrepo folder.

If we assume that there is a command to update subrepo URLs which is
used similar to a normal pull it would be simple to do and could be
automatically executed after a clone.  Normal pulls would not update
the local URLs and as such would not overwrite your personalization.
If you were to revert your local main repo back to a version that
referenced a previous subrepo it would still update just as you expect
and stop using your personalized subrepo.

Perhaps what is really showing here is the need to have a standard
location/method for storing this non-versioned info that you want
transferred when you clone and want to be able to update easily.
Maybe a .hg/etc directory as Jonny mentioned or maybe a standard
extension implementation would be good.  I'm really not sure at this
level but it seems to be an issue that applies to various extensions
that could all probably benefit from some standard solution.

-kyle