Re: Let's discuss about unicode compositions for filenames!
From: Thomas ┼kesson <thomas_at_akesson.cc>
Date: Sun, 12 Feb 2012 16:47:45 +0100
On 11 feb 2012, at 13:10, Hiroaki Nakamura wrote:
Perhaps I did not describe this well enough, but I am _not_ suggesting a normalized repository storage, just normalized uniqueness check during add operations. I believe that a normalized repository storage would cause too much compatibility issues with historical data (as well as other negative effects noted below).
The proposition I outlined has _no_ issues what so ever with existing repositories or working copies, even if they do have name collisions (which we all agree is rare). What would change is the ability to create _new_ name collisions (normalized) while old name collisions could be resolved with 'svn mv'.
I am not sure anyone has yet voiced the opinion that Subversion must continue to accept the creation of new name collisions. Anyone? I think Neels was closest to that opinion that but my interpretation is that he suggested that a Subversion server should not normalize. The more times I read Neels' post (2012-01-30), it is increasingly obvious that what I proposed is very similar.
There is consensus that a high priority for Subversion is compatibility. Introducing a normalization/translation/etc is risky business for compatibility. The HFS+ file system has been chastised (both here and other dev-lists) for its behaviour. A file system is expected to return exactly what was stored, or refuse up-front.
Would it make sense to formalize the different approaches into a couple of RFCs attempting to summarize the respective implications of each approach? I could try to write one up for the "Non-normalizing approach".
This is an archived mail posted to the Subversion Dev mailing list.