Subrepository remapping plan

Martin Geisler mg at lazybytes.net
Tue Aug 31 06:46:02 CDT 2010


Didly <didlybom at gmail.com> writes:

> On Fri, Aug 20, 2010 at 1:34 PM, Martin Geisler <mg at lazybytes.net> wrote:
>
>> Hmm... right, you cannot remap to a path that contains \NN parts
>> since they are all looked up as backreferences. You would instead
>> have to use forward slashes and rely on Windows to do the right
>> thing.
>>
>> Should we install insist that Windows users escape the backslashes
>> and so have to enter
>>
>>  c:\\libs\1   or
>>  c:/libs\1
>>
>> in the above case?

Mads said he would like to see the above syntax, i.e., a syntax where
users are required to enter correct regular expressions by doubling the
backslashes on Windows or by using forward slashes.

> OK, I understand. I think that as long as the documentation is clear
> in that there may be collisions with folders named "\NN" and that to
> avoid them you should use backslashes instead, then there should be no
> problem.

After thinking about it, I also find it bad that we will have such
exceptions to the rules. So I propose we remove the automatic escaping I
put in and let people use backslahes at their own risk.

> When I read the current proposal I had an immediate dislike for the
> idea of mercurial performing chained map substitutions by default. I
> could not quite put my finger on the reason why I did not like it but
> I really did not like it.

My client thinks it's very important that the substitutions are chained
since they want to use this for their third-party supplies, who will
need rules like

  ssh:// = http://company.com/repos/

where they rewrite internal SSH URLs to public HTTP URLs.

> So I've been thinking a bit more about it and I came to the conclusion
> that the reason why I want to be able to bypass the .hg/subpaths file
> is twofold:
>
> 1.- When using symbolic mappings, it would be simpler to make a local
> mapping by performing a substitution on the original symbolic name
> (e.g. replace libfoo with c:\libfoo, rather than replacing
> http://server.com/libfoo with c:\libfoo.

Well, yes and no... I think both are about equally complicated.

> 2.- It would allow the user to create "user mappings" which cannot be
> broken by a change in the central repository submaps file.
>
> Note that #2 is very important because in the best case the mappings
> would simply break (because the source repos would not be found), but
> on the worst case you may end up silently and inadvertently pulling
> from (and pushing to!) the wrong repositories!
>
> For example, imagine that initially there is no .hg/subpaths file. The
> .hgsub file is as follows:
>
> .hgsub:
> libs/foo = libfoo

Oh, if there is no .hg/subpaths file, then you cannot use a .hgsub file
like that! It is very wrong to ask people to setup a [subpaths] setting
in their own configuration files -- or at least that was my intention :)

> .hg/hgrc:
> [subpaths]
> liboo = ../libfoo-stable
>
> Basically the user is using a relative path to point the libfoo
> subrepo to a local clone of the libfoo stable repo.
>
> Now imagine that the administrator creates a .hg/subpaths file with
> the following mapping:
>
> .hg/subpaths:
> libfoo = http://libserver.com/libfoo
>
> Suddenly, and without notice, the subrepo operations would pull and
> push from the central stable repo of the libfoo library! I think that
> this is not safe at all and should be avoided. The example is perhaps
> a bit silly but I believe that there may be similar scenarios that
> could happen in the wild.
>
> Personally I feel that chaining the map substitutions may be dangerous
> and as such it may not be such a good idea. I'd rather mercurial not
> default to that but at least I'd like to have a way to avoid it in my
> own usage of the remapping feature.
>
> Or perhaps I misunderstood how things are supposed to work and I am
> blowing this problem out of proportion?

That is a good question -- nobody knows since nobody has tried this in
production yet :) So the best answer is to plan ahead and make sure we
can extend this system when we get smarter.

Perhaps we can be smarter and have use prefixes to distinguish between
different kinds of substitutions. So if .hg/hgrc contains

  [subpaths]
  libfoo = [final, path] c:\my\libfoo
  lib(.*) = [chained, re] http://libserver/\1

then we will only change 'libfoo' into 'c:\my\libfoo' and skip further
processing on that path -- the substitution is done as str.replace since
we use 'path'. The first 'final' substitution wins.

The second rule is a regular expression marked with 're' and processing
continues after applying it.

My fear with such a scheme is that we are inventing something similar to
Apache's mod_rewrite... the format is very powerful, but also not
intuitive and there are tons of guides out there to help people make
sense of it. I don't want people to become endlessly confused about
these simple remappings.

-- 
Martin Geisler

Mercurial links: http://mercurial.ch/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100831/5011bd3e/attachment.pgp>


More information about the Mercurial-devel mailing list