On Mon, Jan 30, 2012 at 9:09 PM, Branko Čibej <brane_at_xbc.nu> wrote:
> On 30.01.2012 21:00, Johan Corveleyn wrote:
>> On Mon, Jan 30, 2012 at 8:10 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>>> On Tue, Jan 31, 2012 at 01:42:21AM +0900, Hiroaki Nakamura wrote:
>>>> 2012/1/30 Stefan Sperling <stsp_at_elego.de>:
>> [ ... ]
>>
>>> And mixing various unicode forms works fine today if the filesystem
>>> used by the client supports this. The use case Neels contrived, where
>>> developers want to test their code with unicode filenames in various
>>> NFD/NFC forms, and check those test files into Subversion, should still
>>> be supported.
>> Indeed.
>>
>> Though this means that unconditional NFC (or whatever) normalization
>> in the working copy database is not an option, since it precludes
>> representing multiple forms at the same time in the wc. Except maybe
>> dependent on the (filesystem of the) client platform.
>
> Are you seriously proposing that we /support/ such broken, hackish
> nonsense? How do you expect users to tell the difference between file
> names that look identical on the character level, but are not on the
> code point level?
Huh? I'm not proposing anything. Hiroaki suggested (with his patch and
followup discussion) to do normalization to NFC in wc.db (or something
like that, so that all paths that enter wc.db are in NFC form). All
I'm saying is that this conflicts with the "use case
Neels contrived", to represent multiple forms in the working copy.
Except if you allow some clients to do it, and others not (either by a
client-side option, or by platform-specific behavior).
> Supporting such hacks would only be a source of bug reports. I don't see
> this as a desirable feature.
No problem, I don't either. I'm not really participating in this
discussion (got enough discussions going on already :-)). Just wanted
to point out the conflict ...
> And as for doing the server-side checks in pre-commit hooks ... i guess
> you could write a whole libsvn_repos implementation merely as a set of
> pre-commit hooks, but who would want to? Hooks aren't intended for
> implementing core functionality..
Ok, then I also propose that case-insensitive.py should be folded into
core functionality (server-side option). That would be vastly better
of course, more performant etc ...
So I totally agree.
--
Johan
Received on 2012-01-30 21:23:34 CET