Fwd: bfiles filename encoding

[Benoit Boissinot]

Forgot to reply-all, sorry.


---------- Forwarded message ----------
From: Benoit Boissinot <bboissin at gmail.com>
Date: Mon, Jun 7, 2010 at 5:50 PM
Subject: Re: bfiles filename encoding
To: Greg Ward <greg-hg at gerg.ca>


On Mon, Jun 7, 2010 at 3:59 PM, Greg Ward <greg-hg at gerg.ca> wrote:
> On Mon, Jun 7, 2010 at 9:52 AM, Adrian Buehlmann <adrian at cadifra.com> wrote:
>>> So if we reuse fncache in bfiles, either by copying or refactoring,
>>> then bfiles will inherit those two bugs.
>>
>> Windows Vista and Windows 7 explorer strip leading spaces from filenames
>> (see issue1713) when copying trees.
>>
>> I have never looked at bfiles so far, but I assume bfiles *is* already
>> affected by that, or do you already encode leading spaces in filenames?
>>
>> (I'm a bit puzzled by the term "inheriting". How can you inherit
>> something you already have?)
>
> Err, yes, good point.  Currently bfiles does *no* filename encoding
> whatsoever.  So if you put your central store on Windows, you can't
> have big files "foo" and "Foo", you can't have "aux", you can't have "
> foo", and you can't have
> "really/long/path/that/blows/windows/tiny/little/brain".  And if you
> put your central store on OS X, having a big file ".DS_Store" would be
> risky.
>
> Reusing fncache would fix several of those bugs, but not all of them.
> That's really what I was getting at: fncache is better than bfiles'
> status quo, but not perfect.
>
I'm not sure you need the same perf characteristics as hg, so why
can't you just hash the filename (or is that even necessary, can't you
have a git like approach with just blobs indexed by their sha? does
the server need to know the filenames?)

Benoit