Subrepository remapping plan

[Didly]

On Fri, Aug 20, 2010 at 1:34 PM, Martin Geisler <mg at lazybytes.net> wrote:

> Didly Bom <didlybom at gmail.com> writes:
>
> > On Fri, Aug 20, 2010 at 10:24 AM, Martin Geisler <mg at lazybytes.net>
> wrote:
> >
> >> Didly Bom <didlybom at gmail.com> writes:
> >>
> >> Right -- as far as I know Windows is pretty good at accepting forward
> >> slashes instead of backslashes, but I don't know the details, i.e.,
> >> if there are special cases where that doesn't work.
> >
> > Does this mean that the forward-backward slash translation is not done
> > by Mercurial, but by Windows?
>
> Yes, exactly.
>
> > If so then the only way to know if always using "/" rather than "\" is
> > valid on Windows is testing it, which I already did (and it works).
> >
> >> I've pushed a change that escapes backslashes so that only \1, \2,
> >> ... are active. In other words, you can now write
> >>
> >>  lib(.*) = C:\libs\\1
> >>
> >> and 'libfoo' will be replaced with 'C:\libs\foo', which I hope is what
> >> you would expect.
> >
> >
> > I am not sure that I fully understand you. For example, how would you
> > create a substitution that substituted "libfoo" and "libbar" into
> > "c:\libsfoo" and "c:\libsbar"? If you did:
> >
> > lib(.*) = c:\libs\1
>
> Yes, that would be how you do it.
>
> > wouldn't that conflict with a folder named "1" found in c:\libs?
>
> 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?


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.

>> Hmm... I don't like this so much since I think this makes things more
> >> complicted instead of simpler.
> >
> >
> > I don't think that his proposal complicates things because it is
> > transparent for in original use case. Unless a user used wrapped the
> > substitution string with "<" and ">" the substitution will happen as
> > you described in your previous email. It just gives the user an
> > additional option, but it does not need to use it or even know about
> > it..
> >
> > Using "<" and ">" is just an idea. I really would not mind using any
> > other mechanism. What I'd like (if possible) is to have a way to
> > ignore the ".hg/subpaths" file to perform a direct substitution on the
> > .hgsub file.
>
> When using what I've called "symbolic names" for paths (such as
> "libs/foo = libfoo" in .hgsub where "libfoo" needs to be translated into
> a URL) then the .hg/subpaths file is not optional.
>
> The idea is that whoever owns the repository installs it with the
> correct URLs you need to clone. So I'm not sure why you want to bypass
> the .hg/subpaths file as a user.


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. 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.

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

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?

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