Solving long paths by hashing

[Adrian Buehlmann]

Thanks Matt

On 29.06.2008 18:43, Matt Mackall wrote:
> On Sun, 2008-06-29 at 14:38 +0200, Dirkjan Ochtman wrote:
>> Adrian Buehlmann wrote:
>>  > Writing to a single longnames file needs write locking.
>>
>> Yeah, so? You won't be writing to it that often. Only if a new file 
>> added whose name is too long to be encoded normally.
> 
> Indeed, and you're already holding the relevant lock when you do this.
> 
>>  > Plus it's inefficient and scales badly.
>>
>> I don't think so. But feel free to actually argue this...
>>
>>  > Needing to update the longnames file requires complex code and more
>>  > memory (caching).
>>
>> You don't need to update it that often.
> 
> This file can be append-only. We only ever need to write to it when we
> add a new hashed revlog. And we only need to read it when we
> streamclone.
> 
>>  > You have to read the whole longnames file before you can start
>>  > streamcloning.
>>
>> It shouldn't become very large, since most files won't need it.
> 
> Indeed. And it will actually be far more efficient to read this file
> than to walk the tree of hashed files.

I assume this is because the hashed files will be stored in a separate
tree in the store, right?

So streamclone can exclude that part of the store when it does its walk.
(Of course streamclone will still walk the tree of the non-hashed files,
right?)

(I'm just asking to make sure I understood it, thanks in advance.)