Subrepository remapping plan

[Didly Bom]

On Wed, Aug 18, 2010 at 12:21 PM, Martin Geisler <mg at lazybytes.net> wrote:

> Didly Bom <didlybom at gmail.com> writes:
>
> > Hi Martin,
> >
> > I just reviews the updated proposal and overall I think it is very
> > nice although I have a couple of comments:
>
> Thanks for reading it -- note that this is already pushed so you can
> play with it today if you grab a nightly build of TortoiseHg:
>
>  http://bitbucket.org/tortoisehg/thg-winbuild/downloads
>
> > - I am worried about how would back-references work in windows, where
> > there can be paths such as "C:\workspace\1". Perhaps the documentation
> > should explicitly state that paths should use "/" rather than "\",
> > even on windows?
>
> Yeah, I can see how that can cause problems. If a forward slash works
> just as well as a backslash on Windows, then please edit the page to
> give that hint.
>

Well, I tried it on my WindowsXP SP3 x86 machine and it seems to work.
However, I think that it would be much safer to confirm whether it is
_supposed_ to work (i.e. that Mercurial does support using forward slash
rather than backslash for paths on windows). I wouldn't like to make an
unconfirmed recommendation and I am not sure that just testing it on my
system is enough to confirm that this recommendation would work.

The replacement is done using re.sub:
>
>  >>> re.sub('libfoo', r'c:\x\y', 'libfoo')
>  'c:\\x\\y'
>
> As you can see, unrecognized escape  sequences are left alone. However,
> it is probably recognizing more than it should:
>
>  >>> re.sub('libfoo', r'c:\a\b', 'libfoo')
>  'c:\x07\x08'
>
> Here \a and \b are valid escape sequences... this is not optimal :) I
> think I'll need to escape the backslashes again...
>
> > - I am not sure that applying substitutions on top of each other by
> > default is a good idea. For example, in your own example, you have the
> > following configuration:
> >
> >
> > .hgsub:
> > libs/foo = libfoo
> >
> > .hg/subpaths:
> > libfoo = http://server.com/libfoo
> >
> > .hg/hgrc:
> > [subpaths]
> > ^http://server.com/ = ssh://localhost:1234/
> >
> > Now imagine that the adminstrator of the central repo changes the
> > .hg/subpaths file to:
> >
> > .hg/subpaths:
> > libfoo = http://newserver.com/libfoo
> >
> > Wouldn't that break the local .hg/hgrc subpaths mapping?
>
> Yes, it would. I think this is okay -- the goal is to make it easy for
> an admin to provide the right mapping to everybody and still make it
> possible for people to override the mapping on occasion. The latter is
> the exception and I am OK with requiring that people update their
> mappings when the master mapping changes.


I think that it would be nice if you could still somehow override the chain
remapping and refer to the original map (the one that is set on the .hgsub
file) while defining your local remappings. This would solve the issue I
previously mention and it would make it simpler for the user to do a quick
override, since there would be one less file to check (one would just need
to look at the original mappings on the .hgsub file, rather than also
looking at the .hg/subpaths file).

For instance, we could let the user wrap the substitution string around "<"
and ">" (which are characters that cannot be used as part of a file name, at
least on Windows). This could mean that the map must be performed with
respect with the contents of the .hgsub file, ignoring any other maps (found
in .hg/subpaths, for instance).

In your example, we could do:

.hgsub:
libs/foo = libfoo

.hg/subpaths:
libfoo = http://server.com/libfoo

.hg/hgrc:
[subpaths]
<libfoo> = ssh://localhost:1234/

Thus, bypassing the .hg/subpaths mapping. You could even do:

.hg/hgrc:
[subpaths]
<^libfoo> = ssh://localhost:1234/

If you wanted to make sure that the substitution is performed only when
libfoo is found at the beginning of the mapping.

I feel that this would give the user full control over subrepository
mappings, and keep the flexibility of your original proposal.

Cheers,

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