Subrepository remapping plan

Martin Geisler mg at lazybytes.net
Fri Aug 20 03:24:13 CDT 2010


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.

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

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

-- 
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/20100820/f66fe5b7/attachment.pgp>


More information about the Mercurial-devel mailing list