On 07.12.2013 19:26, Thomas Ã…kesson wrote:
> On 29 nov 2013, at 21:09, Branko ÄŒibej <brane_at_wandisco.com> wrote:
>
>> On 29.11.2013 20:42, Ivan Zhakov wrote:
>>> On 29 November 2013 22:22, <brane_at_apache.org> wrote:
>>>> Author: brane
>>>> Date: Fri Nov 29 18:22:00 2013
>>>> New Revision: 1546619
>>>>
>>>> URL: http://svn.apache.org/r1546619
>>>> Log:
>>>> * branches/fsfs-ucsnorm/BRANCH-README: New file.
>>>>
>>>> Added:
>>>> subversion/branches/fsfs-ucsnorm/BRANCH-README (with props)
>>>>
>>>> Added: subversion/branches/fsfs-ucsnorm/BRANCH-README
>>>> URL: http://svn.apache.org/viewvc/subversion/branches/fsfs-ucsnorm/BRANCH-README?rev=1546619&view=auto
>>>> ==============================================================================
>>>> --- subversion/branches/fsfs-ucsnorm/BRANCH-README (added)
>>>> +++ subversion/branches/fsfs-ucsnorm/BRANCH-README [UTF-8] Fri Nov 29 18:22:00 2013
>>>> @@ -0,0 +1,66 @@
>>>> +The purpose of this [fsfs-ucsnorm] branch is to implement two optional
>>>> +checks related to Unicode normalisation to FSFS.
>>>> +
>>>> +
>>>> +Option: Prevent name collisions
>>>> +===============================
>>>> +
>>>> +If this option is enabled, FSFS will reject operations that would
>>>> +create two different representations of the same name in the same
>>>> +directory. This will prevent situations where a user could see more
>>>> +than one form of the name in a directory listing:
>>> Nice feature, but why in FS layer? May be it's better to implement
>>> this feature on svn_repos layer?
>> It's not, for at least two reasons:
>> Users of the FS API must have the same constraints as repository clients, otherwise the whole thing falls on its face.
>> The repos layer cannot implement this optimally; at a rough guess, it would have to double the number of lookups performed:
>> The node cache in an FSFS implementation detail, and this option will affect how cache keys are generated.
>> Likewise for actual lookups into the on-disk representation.
Hi Thomas.
> Just want to say that, in my opinion, the design described in BRANCH-README since r1546640 looks very good.
Thanks. It's finally in a shape where I'm happy with it, too.
> You might remember from back when I did some specification work (in the wiki) that I am a strong proponent of the "normalization-preserving" approach to the problem. I believe n-p makes many issues dealing with existing repositories much easier to manage, in most cases go away completely unless there are actually normalization conflicts.
Agreed. The only "problem" with this approach is that it affects
performance; but I'm hoping that the effect will be minor.
> E.g. the issue raised by Bert 2013-11-24 regarding mergeinfo is not a problem with n-p (I guess without thinking too much about it).
Mergeinfo really has all the same problems as paths; in both cases, both
the server and the client have to be normalization-agnostic and
-preserving in all their path and mergeinfo operations.
-- Brane
--
Branko ÄŒibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2013-12-08 10:56:54 CET