On Fri, Sep 21, 2012 at 11:16 AM, Adrian Buehlmann <span dir="ltr"><<a href="mailto:adrian@cadifra.com" target="_blank">adrian@cadifra.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br></div>
Encoding-wise, basic-encoding is - in theory - overkill for hashed paths.<br></blockquote><div><br></div><div>You're right, and I could have been clearer about why I think it makes sense to do so anyway.</div><div><br>
</div><div>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.</div><div><br></div><div>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.</div>
<div><br></div><div>By having one code path for both cases, we have less complexity, less stuff to audit, and less code to go wrong.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For example, "the encoding code we already have" *includes* direncoding<br>
- but that's unneeded.<br></blockquote><div><br></div><div>True, but to dir-encode in one case and not another adds complexity.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the direncoding doesn't survive directory-truncation, as the ".hg"<br>
ending of an "xxx.i.hg" may be truncated away, thus producing the<br>
unwanted ".i" ending again.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Am I making sense?</div></div>