Subrepository remapping plan

[Didly Bom]

On Fri, Aug 20, 2010 at 10:24 AM, Martin Geisler <mg at lazybytes.net> wrote:

> Didly Bom <didlybom at gmail.com> writes:
>
> > On Wed, Aug 18, 2010 at 12:21 PM, Martin Geisler <mg at lazybytes.net>
> wrote:
> >
> >> Didly Bom <didlybom at gmail.com> writes:
> >>
> >> > - 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.
>
> 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? 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

wouldn't that conflict with a folder named "1" found in c:\libs?



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

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