Subrepository remapping plan

[Didly]

On Fri, Jul 23, 2010 at 3:52 PM, Martin Geisler <mg at aragost.com> wrote:

> Didly <didlybom at gmail.com> writes:
>
> >> On Fri, Jul 23, 2010 at 13:38, Martin Geisler <mg at aragost.com> wrote:
> >
> > On Fri, Jul 23, 2010 at 1:47 PM, Dirkjan Ochtman <dirkjan at ochtman.nl>
> wrote:
> >
> >>> I've made a wiki page that describes what I'm planning on
> >>> implementing for remapping URLs in the .hgsub file:
> >>>
> >>>  http://mercurial.selenic.com/wiki/SubrepoRemappingPlan
> >>>
> >>> Please take a look and tell me if you think this will solve your
> >>> problems. The plan comes from the company that has hired me to
> >>> implement this, and we believe it will solve their problems.
> >>
> >> - Why do we need the intermediate key "libfoo"? It seems like we
> >> could just use the in-repo path to the subrepo to key off of (i.e.
> >> the subpaths file or hgrc would have lib/foo =
> >> http://hg.company.com/libraries/libfoo). It might change location in
> >> the repo, but it wouldn't be hard to add an extra mapping entry (the
> >> libfoo is also prone to being renamed at some point).
> >
> > I believe that the reason for the intermediate key "libfoo" is not
> > really stated on the wiki and it is that (at least originally) the
> > subpath entries are meant to be used to substitute the beginning of
> > the source paths, rather than the full source paths. That is, if your
> > hgsub file was:
> >
> > libfoo = libfoo/my/custom/path/to/libfoo
> >
> > then setting a subpaths mapping such as:
> > libfoo = http://myserver/libfoo
> >
> > would be equivalent to having the following hgsub file:
> >
> > libfoo = http://myserver/libfoo/my/custom/path/to/libfoo
> >
> > Martin, is that right?
>
> I was about to add a section about remapping prefixes only... but I'm
> starting to doubt if it is really so sensible. One problem is that if
> you have a .hgsub file with
>
>  libs/foo     = libfoo
>  libs/fooplus = libfooplus
>
> then you cannot remap 'libfoo' only since it is also a prefix of
> 'libfooplus'. So I was starting to explain something about only
> remapping prefixes that end with a '/', so that you can remap a .hgsub
> file containing
>
>  libs/foo = http://server.com/libraries/foo
>  libs/bar = http://server.com/libraries/bar
>  libs/baz = http://server.com/libraries/baz
>
> with a .hg/hgrc file containing
>
>  [subpaths]
>  http://server.com/ = ssh://localhost:1234/
>
> But it suddenly seemed a bit messy to me and I left it out from the
> proposal. So now it's just mapping one string to another.
>

This may seem a bit messy, but I see a non small problem with leaving that
feature out: Changing the location of the top repository would require
adding one mapping per subrepo.

This has several undesired consequences:

1. On moderately to complex subrepo configurations (e.g. with more than 10
subrepos), configuring the subpaths to account for a simple server name
change would be very inconvenient and also very messy! Basically you would
be trading simplicity on the feature side for messiness on the configuration
side. My feeling is that this is not a good trade off.

2. As a consequence of #1, it would be much harder to adapt existing setups
to make use of this new feature.

3. The subpath file would be harder to maintain.

4. subpath mappings would be repository specific since each subrepo would
need to be mapped individually. It would not be possible, for instance, to
add a submap section to the global hgrc file and have it apply to all your
subrepos, for instance.

I think that a compromise could be reached. For instance, the substitution
could be done on a "complete word" basis. That is, a mapping for libfoo
would apply in cases such as:

libfoo = libfoo
libfoo = libfoo/
libfoo = libfoo/mysubfolder

But not in:

libfoo = libfoo2

As another example, a mapping for http://myserver/myfolder would apply to:

libfoo = http://myserver/myfolder
libfoo = http://myserver/myfolder/myotherfolder

But not in

libfoo = http://myserver/myfolder2

and so on.

I think this would be easy to explain yet powerful and it would also avoid
the "similar subrepo names" pitfall that you pointed out.

Cheers,

Angel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100723/ee83035e/attachment.htm>