Subrepository remapping plan

[Martin Geisler]

Didly <didlybom at gmail.com> writes:

> On Fri, Jul 23, 2010 at 4:54 PM, Didly <didlybom at gmail.com> wrote:
>
> Some additional thoughts:
>
> - An additional drawback of not being able to use "partial
> substitutions" would be that it would make it harder “but not
> impossible) to switch back and forth between two subrepository source
> "roots". For example, imagine that your primary server went down and
> you wanted to start using an alternative mirror server until the
> primary server was up again. With partial substitutions this could be
> as simple as making a single mapping, which you could probably reuse
> for all your repositories. With the proposed solution you would need
> to make a lot of individual mappings concering every subrepo used in
> every repository.

Yeah, I see what you mean. Matt proposed to use regular expressions for
the remapping and I kind of like that idea since it is very powerful
while also being standard.

We would even get the prefix replacement scheme almost for free! So you
can write this in the .hg/subpaths file:

  ^http://old-company.com/ = http://new-company.com/

and this will replace the domain name in your URLs. The ^ is not
strictly necessary, unless you are afraid that you will have "http://"
appearing more than once in your URLs (highly unlikely/impossible).

The replacement will be done by expanding backreferences to matched
groups, so you can write

  http://server/(.*)-hg/ = http://hg.server/\1/

to replace

  http://server/foo-hg/

with

  http://hg.server/foo/

People using "symbolic names" wont notice this since they just write

  libfoo = http://hg.company.com/libraries/libfoo

like before. My concern with the prefix-replacements was that one cannot
use both "libfoo" and "libfoo2" as symbolic names, but this is solved by
having people write

  libfoo$ = http://hg.company.com/libraries/libfoo
  libfoo2 = http://hg.company.com/libraries/libfoo2

that is, by explicitly requiring that "libfoo" match the end.

What do you think of this idea?

> - In the wiki you explain that the subpaths file is propagated to the
> clients automatically on pull. However, it is unclear (to me) what
> would happen on push. Could a careless or uninformed developper change
> everybody's subrepo mappings by pushing his customized subpaths file
> to the central repository?

This is a good question! The company I work for was also concerned about
this exact point and concluded that they didn't want anything to happen
on push. That way it is only a trusted administrator that can configure
the central remapping by directly editing the .hg/subpaths file.

But now that you raise the question, I realize that this will be a
problem for sites such as Bitbucket or Google Code unless they provide
an editor for this file.

Propagating the .hg/subpaths file will be a second step anyway. The
first step will be to add the remapping.

> - This proposal seems to cover one of the two current issues with
> subrepos. Namelly, making it possible to change the subrepo sources
> without breaking the hability to go back to old revisions. However it
> does not seem to fix the second problem with subrepos, which is that
> you cannot make clone chains when using subrepos. I think that this
> could be achieved with some changes to the proposal.
>
> For example, perhaps we could add a way to add an additional level of
> indirection in which the subpaths mappings (or even the hgsub mappings
> themselves) can be linked to the top repository default path. That way
> the subrepo mappings could be changed automatically each time you
> create a new clone, since the default repository path of the top repo
> allways points to the clone source.
>
> I am still not 100% clear on this idea, but I feel that a good
> solution to the clone chain problem is lurking and waiting to be
> uncovered with this proposal :)

That would indeed be nice, but I don't see it right now.

> - When subrepo sources where "fixed" (at least for a certain revision"
> it made sense to always to do a full push of all subrepos when pushing
> the top repository. However it seems to me that now that the subrepo
> sources could become more variable perhaps that does not make so much
> sense anymore (I just don't know but it may be worth to think about
> it). Perhaps only the subrepo revisions up to the currently selected
> revision (or in any revision of the top folder that is being pushed)
> should be pushed?

Hmm... yeah... more good questions... I think that is all I can say
right now :-)

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/