[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Comments on 'notes/unicode-composition-for-filenames'

From: Branko Čibej <brane_at_e-reka.si>
Date: Tue, 22 Feb 2011 20:44:39 +0100

On 22.02.2011 20:11, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Feb 22, 2011 at 19:41:12 +0100:
>> On 22.02.2011 18:17, Julian Foad wrote:
>>> For example, a solution that involves normalizing all input to NFD would
>>> have the advantages that on MacOSX it would need to do *no* conversions
>>> and would continue to work with old repositories in Mac-only workshops.
>> You'd make this configurable? But how? How do you prove that paths in
>> old repositories are normalized in a certain way? You can only assume
>> that for paths that you know were normalized before being written to the
>> repository. And even then, you can't assume too much -- an older tool,
>> without normalization, can still write denormalized strings to the
>> repositury vial file://. Unless you want to have an explicit flag for
> Really? So the FS layer wouldn't be aware of NFC v. NFD?

It should certainly normalize them, but there's no guarantee that an
older tool wasn't linked to an older libsvn_repos/fs (whilst still being
compatible with the FS layout). I admit that's not a nice way to do
things, but it can happen. We'd either have to allow for this case,
which implies normalizing paths as we read them from the repository; or,
make the normalization mandatory with an "incompatible" FS version bump,
but then you'd have to do a complete dump/reload cycle in order to
upgrade your FS to that version.

I'm guessing not everyone will want to do the dump/reload thing ... but
the noremalize-on-read could probably be made dependent on the FS version.

-- Brane
Received on 2011-02-22 20:45:17 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.