On 12.11.2012 18:34, Bert Huijben wrote:
>> -----Original Message-----
>> From: Branko Čibej [mailto:brane_at_wandisco.com]
>> Sent: maandag 12 november 2012 17:49
>> To: dev_at_subversion.apache.org
>> Subject: Re: svn commit: r1408325 - /subversion/branches/wc-collate-
>> path/subversion/libsvn_subr/sqlite.c
>>
>> It's all described and discussed here:
>>
>> http://wiki.apache.org/subversion/UnicodeComposition
>>
>> This branch is only exploring the client-side effects. The server needs
>> to adjust to make the whole thing bullet-proof.
> 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 don't think we can just apply a UNIQUE constraint or something without breaking compatibility?
>
>
> I would have hoped to see an explanation on what you are trying to resolve in a BRANCH-README or in the Wiki.
> And given the information in 'unicode-composition-for-filenames' I don't see a libsvn_wc only solution to these issues.
>
>
> [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.
> And whether or not it is such an experiment, a branch readme should document that.
>
> See http://subversion.apache.org/docs/community-guide/general.html#branch-readme-files.
>
>
>
> 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.
Bert, I hear you. I'm well aware of the issues. I'll be able to say more
about the design when I have a better idea of what's needed. Personally
I like to explore these kinds of dependencies in code, and only later
extract a detailed design. In the meantime, if it makes you feel better,
you can treat that branch as my private playground that's never intended
to be merged back to trunk as-is.
-- Brane
Received on 2012-11-13 11:01:02 CET