subrepo: what about making subrepo URLs configurable

[JonnyDee]

On Feb 18, 9:09 pm, Brendan Cully <bren... at kublai.com> wrote:
> On Thursday, 18 February 2010 at 11:51, Kyle Altendorf wrote:
> > On Thu, Feb 18, 2010 at 11:02, Brendan Cully <bren... 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 <st... 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.
>
> No, I'm not suggesting that. The syntax above is a new abstraction
> layer that in my opinion just pushes the problem of finding the
> correct URL down. I'm proposing a way to override actual URLs.

I don't see a problem in introducing such an abstraction layer (as you
call it) which abstracts away the problem of having an unchangable
history versus a constantly changing environment around the
repository. To me, overriding URLs sounds like a hack which may be
easy to implement, but it would also harm Mercurial's clean design. I
mean what does 'overriding URLs' actually mean? To me, it sounds a bit
strange... It feels like glueing a peace of paper over an outdated
address in order to 'override' it with the new one. Of course, this
solution solves the problem somehow, but from a design point of view
it doesn't remove the fact that the idea of using a versioned .hgsub
assumes the repository's surrounding environment only evolves along
with the repository's history and can even be rolled back to an
earlier state. I believe that introducing a corresponding abstraction
layer that explicitly deals with the issue of having an environment
which cannot be controlled (particularly in a distributed context)
better models reality and makes Mercurial's implementation of subrepos
cleaner.

> > 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.
>
> It sounds to me like a URL override would cover this too.
>
> > 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.
>
> This is the tags problem again. My personal preference is for a
> separate metadata head, but that'd take a bit more discussion to hash
> out.

I'm not sure what you mean with metadata head, but if that head is
versioned...wouldn't this result in exactly the same problem? You
would try to write down something in a static history which is
inherently dynamic.

Anyway, why isn't it a good idea to have some .hg/etc directory (or
however you might call it) which gets cloned along with a repository?
Extensions could place their configuration files there and others
cloning from a repository would also get the configurations out of the
box.

Or instead, you could implement/see it like this: A Mercurial
repository could contain two storages, a versioned one and an
unversioned one. And you could check your sources in into the one or
the other. If you find you have information which should not be
versioned place it into the unversioned storage, if you want
versioning support put it in the other one. There is really no
difference, except one storage tracks history. A pull would, in the
unversioned case, just get the unversioned data from the parent
repository (and overwrite the local one), while in the versioned case
new revisions will be pulled. An update would check out the
unversioned content into the file tree as it does for versioned data.
A commit would, in the unversioned case, just overwrite the files in
the unversioned storage. In the versioned case a new revision gets
added to history. And so on... I hope I could make my idea clear
enough. It's similar to Kyle's idea I think...

Best regards,
Jonny