[prev in list] [next in list] [prev in thread] [next in thread]
List: subversion-dev
Subject: Re: svn commit: r1546619 - /subversion/branches/fsfs-ucsnorm/BRANCH-README
From: Branko Čibej <brane () wandisco ! com>
Date: 2013-11-29 20:09:11
Message-ID: 5298F467.5080709 () wandisco ! com
[Download RAW message or body]
On 29.11.2013 20:42, Ivan Zhakov wrote:
> On 29 November 2013 22:22, <brane@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:
o The node cache in an FSFS implementation detail, and this option
will affect how cache keys are generated.
o Likewise for actual lookups into the on-disk representation.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane@wandisco.com
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 29.11.2013 20:42, Ivan Zhakov wrote:<br>
</div>
<blockquote
cite="mid:CABw-3YfUKruMYa-hh+JvOkxDUAZBRr3NSF_EL3XLceEseO_y7w@mail.gmail.com"
type="cite">
<pre wrap="">On 29 November 2013 22:22, <a class="moz-txt-link-rfc2396E" \
href="mailto:brane@apache.org"><brane@apache.org></a> wrote: </pre>
<blockquote type="cite">
<pre wrap="">Author: brane
Date: Fri Nov 29 18:22:00 2013
New Revision: 1546619
URL: <a class="moz-txt-link-freetext" \
href="http://svn.apache.org/r1546619">http://svn.apache.org/r1546619</a> 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: <a class="moz-txt-link-freetext" \
href="http://svn.apache.org/viewvc/subversion/branches/fsfs-ucsnorm/BRANCH-README?rev= \
1546619&view=auto">http://svn.apache.org/viewvc/subversion/branches/fsfs-ucsnorm/BRANCH-README?rev=1546619&view=auto</a>
==============================================================================
--- 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:
</pre>
</blockquote>
<pre wrap="">Nice feature, but why in FS layer? May be it's better to implement
this feature on svn_repos layer?
</pre>
</blockquote>
<br>
It's not, for at least two reasons:<br>
<ul>
<li>Users of the FS API must have the same constraints as
repository clients, otherwise the whole thing falls on its face.</li>
<li>The repos layer cannot implement this optimally; at a rough
guess, it would have to double the number of lookups performed:<br>
</li>
<ul>
<li>The node cache in an FSFS implementation detail, and this
option will affect how cache keys are generated.</li>
<li>Likewise for actual lookups into the on-disk representation.</li>
</ul>
</ul>
-- Brane<br>
<br>
<br>
<div class="moz-signature">-- <br>
<span style="font-face:sans-serif;font-size:9pt;line-height:18pt">Branko
Čibej <span style="color: #f90">|</span> <span
style="font-weight:bold">Director of Subversion</span>
<br>
WANdisco <span style="color: #f90">//</span> <span
style="font-style:oblique">Non-Stop Data</span>
<br>
<span style="color: #ccc">e.</span> <a class="moz-txt-link-abbreviated" \
href="mailto:brane@wandisco.com">brane@wandisco.com</a></span></div> </body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic