Possibly changing the path encoding format
adrian at cadifra.com
Wed Sep 12 16:21:46 CDT 2012
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).
> Sounds good to me. I was actually hoping you would make a proposal in
> I'd be happy to do the work to implement this, but this is one of those
> rare cases where it's less work to describe the desired behaviour in
> English than in code.
I can't execute English :-). But fair enough.
FWIW, I forgot to mention that one of the motivations of the current
hashed encoding implementation was not to waste precious characters for
uppercase chars (the X -> _x dance). Back at the time I thought that
there isn't really that much point in wasting path length with
underbars, since we already have a distinctive hash in the path anyway.
That's why I then proposed doing
aep = auxencode(lowerencode(ndpath))
and the patch was accepted.
But maybe it wasn't worth the trouble.
In general I feel the current hashed encoding is way too complicated. It
should be made as simple as reasonable. It really hurts when having to
look at it through C code.
Let's see what Matt's feelings about yet another repo format change are.
More information about the Mercurial-devel