RE: svn commit: r1408325 - /subversion/branches/wc-collate-path/subversion/libsvn_subr/sqlite.c

> -----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
Received on 2012-11-12 18:35:21 CET