Possibly changing the path encoding format

Adrian Buehlmann adrian at cadifra.com
Thu Sep 13 02:37:35 CDT 2012


On 2012-09-13 07:28, Matt Mackall wrote:
> On Wed, 2012-09-12 at 23:21 +0200, Adrian Buehlmann wrote:
>> On 2012-09-12 22:11, Bryan O'Sullivan wrote:
>>> On Wed, Sep 12, 2012 at 12:28 PM, Adrian Buehlmann <adrian at cadifra.com
>>> <mailto:adrian at cadifra.com>> wrote:
>>>
>>>
>>>     I agree that my auxencode2 possibly wouldn't change much compared to
>>>     current auxencode. But you could drop the logic around where the periods
>>>     are.
>>>
>>>
>>> In principle yes, but in practice the small reduction in C code would be
>>> counterbalanced by introducing a new code path in Python, as we can't
>>> drop the current fncache encoding stuff until the sun goes dark.
>>
>> Agreed. It's clear that we can't drop any encoding in use.
>>
>> However, the thing is, this will probably be the very last chance to
>> jump on a repo format change bandwagon (provided we get the ok from Matt
>> for a new repo format at all).
> 
> I'm ok with it, but I think we should beat the bushes to make sure we've
> really, finally thought of everything.

Thanks.

I totally agree with the need to "beat the bushes" thing.


Let me list here for easy reference for everyone some noteworthy things
from the history. This might help to prevent repeating similar bad
things or just sharpen everyone's thinking (especially my own!).

An example of a past horror caused by me is this one:

  http://bz.selenic.com/show_bug.cgi?id=1417

which was fixed with

  http://selenic.com/repo/hg/rev/e54cf540c6ca
  http://selenic.com/repo/hg/rev/ee5aba886108

Bug 1417 was caused by me failing to read and observe "Do not end a file
or directory name with a space or a period" as stated on

  http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

Another example is

  http://bz.selenic.com/show_bug.cgi?id=1713

That one solved a stupidity around Windows Explorer of Windows 7 and
Vista (which I haven't seen documented). When copying trees, it
*removes* all spaces from the beginning of file and directory names.

This was fixed with

  http://selenic.com/repo/hg/rev/34d8247a4595

which introduced the dotencode format. That format also solved:

  "Mac OS X has problems with filenames starting with '._'
  (e.g. '.FOO' -> '._f_o_o' is now encoded as '~2e_f_o_o')"


More information about the Mercurial-devel mailing list