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
