RE: svn commit: r1408325 - /subversion/branches/wc-collate-path/subversion/libsvn_subr/sqlite.c
From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 12 Nov 2012 18:34:36 +0100
> -----Original Message-----
I don't see a discussion of and/or answers to many questions in http://svn.apache.org/repos/asf/subversion/trunk/notes/unicode-composition-for-filenames in there.
The most important: How are you going to handle the current hashtable approach in performance critical things like 'svn status'?
[I don't think a WIKI is the right place to discuss such topics, but that is a different topic]
This involves a solution for how you are going to handle duplicate names. Many existing users only find these problems after committing a problematic file. In many cases they will remove that file and maybe add the same name with a different encoding. A mixed revision working copy (or an svn up from one to the other) can then have both files.
A normalization library and the right collate indexes won't resolve those problems.
I would have hoped to see an explanation on what you are trying to resolve in a BRANCH-README or in the Wiki.
[Patching libsvn_subr/sqlite.c -used by the repository and client- to only support a single new collate on opening, might by itself break upgrade scenarios from 1.7.]
I really think some design is necessary if this branch tries to be more than some experiment that we don't intend to merge back to trunk.
Re: your other mail with the same subject.
I don't think we as a project like patch bombs.
I started asking about the design, to avoid the pain of a late review of huge changes all over the place with unknown impact.
I don't want to turn a patch for such an important issue into something which we won't be able to apply later because nobody is able to review it.
This is an archived mail posted to the Subversion Dev mailing list.