subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jcor...@apache.org
Subject svn commit: r1750285 - /subversion/site/publish/faq.html
Date Mon, 27 Jun 2016 07:18:48 GMT
Author: jcorvel
Date: Mon Jun 27 07:18:48 2016
New Revision: 1750285

URL: http://svn.apache.org/viewvc?rev=1750285&view=rev
Log:
* site/publish/faq.html
  (readonly): Move this question to the BDB Questions under the Deprecated FAQ

Modified:
    subversion/site/publish/faq.html

Modified: subversion/site/publish/faq.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/faq.html?rev=1750285&r1=1750284&r2=1750285&view=diff
==============================================================================
--- subversion/site/publish/faq.html (original)
+++ subversion/site/publish/faq.html Mon Jun 27 07:18:48 2016
@@ -79,7 +79,6 @@ For older questions, see <a href="#depre
 <li><a href="#nfs">Should I store my repository / working copy on a
     NFS server?</a></li>
 <li><a href="#reposperms">How do I set repository permissions correctly?</a></li>
-<li><a href="#readonly">Why do read-only operations still need repository write
access?</a></li>
 <li><a href="#removal">How do I completely remove a file from the repository's
history?</a></li>
 <li><a href="#change-log-msg">How do I change the log message for a revision
     after it's been committed?</a></li>
@@ -1144,32 +1143,6 @@ access the repository.</p>
 
 
 
-<div class="h3" id="readonly">
-<h3>Why do read-only operations still need repository
-write access?
-  <a class="sectionlink" href="#readonly"
-    title="Link to this section">&para;</a>
-</h3>
-
-<p>Certain client operations are "read-only", like checkouts and
-updates.  From an access-control standpoint, Apache treats them as
-such.  But libsvn_fs (the repository filesystem API) still has to
-write temporary data in order to produce tree-deltas.  So the process
-accessing the repository always requires both read <em>and</em> write
-access to the Berkeley DB files in order to function.</p>
-
-<p>In particular, the repository responds to many "read-only"
-operations by comparing two trees.  One tree is the usually the HEAD
-revision, and the other is often a temporary transaction-tree -- thus
-the need for write access.</p>
-
-<p>This limitation only applies to the Berkeley DB backend; the <a
-href="http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.fsfs"
->FSFS backend</a> does not exhibit this behaviour.</p>
-
-</div>
-
-
 <div class="h3" id="removal">
 <h3>
 How do I completely remove a file from the repository's history?
@@ -4237,6 +4210,7 @@ Berkeley DB a repository is using?</a></
     calls". How do I fix this?</a></li>
 <li><a href="#bdb43-upgrade">After upgrading to Berkeley DB
     4.3 or later, I'm seeing repository errors.</a></li>
+<li><a href="#readonly">Why do read-only operations still need repository write
access?</a></li>
 </ul>
 </div>
 
@@ -4707,10 +4681,35 @@ etc.)</li>
 </div>
 
 
+<div class="h3" id="readonly">
+<h3>Why do read-only operations still need repository
+write access?
+  <a class="sectionlink" href="#readonly"
+    title="Link to this section">&para;</a>
+</h3>
+
+<p>Certain client operations are "read-only", like checkouts and
+updates.  From an access-control standpoint, Apache treats them as
+such.  But libsvn_fs (the repository filesystem API) still has to
+write temporary data in order to produce tree-deltas.  So the process
+accessing the repository always requires both read <em>and</em> write
+access to the Berkeley DB files in order to function.</p>
+
+<p>In particular, the repository responds to many "read-only"
+operations by comparing two trees.  One tree is the usually the HEAD
+revision, and the other is often a temporary transaction-tree -- thus
+the need for write access.</p>
+
+<p>This limitation only applies to the Berkeley DB backend; the <a
+href="http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.basics.backends.fsfs"
+>FSFS backend</a> does not exhibit this behaviour.</p>
+
 </div>
 
+
 </div>
 
+</div>
 
 </div>
 </body>



Mime
View raw message