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

Re: [RFC] Non-normalizing Unicode Composition Awareness

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 09 Nov 2012 14:46:45 +0100

On 09.11.2012 14:28, C. Michael Pilato wrote:
> On 11/09/2012 07:49 AM, Branko Čibej wrote:
>> On 09.11.2012 12:28, Thomas Åkesson wrote:
>> I'm currently doing the grunt work of implementing the collation (done)
>> and the LIKE and GLOB operators that we'll need (in progress). The next,
>> and biggest, step will be to review the client and WC libraries to make
>> sure that paths sent to the server always come from the wc.db, not from
>> disk.
> I'm not closely following this problem or solution, but how does the above
> play out for "svn import", "svn mkdir IRI", "svn delete IRI", etc? (If this
> is documented somewhere, a reference by way of response would suffice.)

Since these are server-side operations with no working copy involvement,
and I'm doing this strictly client-side for now, nothing would change.
This is a problem that we'll eventually have to solve on the server as
well. I don't believe it would be correct for the client to verify that
such operations do not create normalization conflicts on the server.

As a matter of interest, a server-side solution is one of the features
we identified for FSv2; although there's no reason to wait for that. In
FSv2, I envision all names being stored twice, once in their original
form, and once NFC-normalized, for indexing. The reason for that is that
I expect server CPU cycles to be more expensive than server storage, and
it therefore makes sense to avoid using a relatively expensive
normalizing collation in the server metadata index.

This /may/ turn out to be an issue for client working copy performance,
too; but for now I've elected to assume that collation won't have a
noticeable effect. If it does, we'll look at other solutions.

-- Brane

Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Received on 2012-11-09 14:47:23 CET

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