Possibly changing the path encoding format

[Bryan O'Sullivan]

On Fri, Sep 21, 2012 at 11:16 AM, Adrian Buehlmann <adrian at cadifra.com>wrote:

>
> Encoding-wise, basic-encoding is - in theory - overkill for hashed paths.
>

You're right, and I could have been clearer about why I think it makes
sense to do so anyway.

The reason is that doing some *other* kind of encoding means having to
write more code, or complicating existing code paths so that they do one
thing in case A but another in case B.

This is much of the reason why the current C implementation of hashed
encoding is alarmingly complex: I had to special-case all the things that
it does differently than basic encoding.

By having one code path for both cases, we have less complexity, less stuff
to audit, and less code to go wrong.

For example, "the encoding code we already have" *includes* direncoding
> - but that's unneeded.
>

True, but to dir-encode in one case and not another adds complexity.


> Also, the direncoding doesn't survive directory-truncation, as the ".hg"
> ending of an "xxx.i.hg" may be truncated away, thus producing the
> unwanted ".i" ending again.
>

As far as I can tell, ending a directory in .i won't matter under "dh/", as
it will be impossible for directory and file names to clash in the same way
as they can under "data/". Under "dh/", directory names are always short,
and file names are always long.

Am I making sense?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20120921/404af8a1/attachment.html>