On 12.11.2012 18:34, Bert Huijben wrote: >> -----Original Message----- >> From: Branko Čibej [mailto:br...@wandisco.com] >> Sent: maandag 12 november 2012 17:49 >> To: dev@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
