Possibly changing the path encoding format
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
>>> 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.
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:
which was fixed with
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
Another example is
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
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