[svnbook commit] r2694 - trunk/src/en/book

cmpilato noreply at red-bean.com
Fri Feb 23 01:19:39 CST 2007

Author: cmpilato
Date: Fri Feb 23 01:19:38 2007
New Revision: 2694


* src/en/book/ch-repository-admin.xml
* src/en/book/ch-fundamental-concepts.xml
* src/en/book/ch-server-configuration.xml
* src/en/book/ch-developer-info.xml
  Consistently use URL schemas with two trailing slashes (so, file://
  and https://, not file:/// or http:)

Modified: trunk/src/en/book/ch-developer-info.xml
--- trunk/src/en/book/ch-developer-info.xml	(original)
+++ trunk/src/en/book/ch-developer-info.xml	Fri Feb 23 01:19:38 2007
@@ -406,8 +406,8 @@
       <para>Since Subversion uses URLs to identify its repository
         resources, the protocol portion of the URL schema (usually
-        <literal>file:</literal>, <literal>http:</literal>,
-        <literal>https:</literal>, or <literal>svn:</literal>) is used
+        <literal>file://</literal>, <literal>http://</literal>,
+        <literal>https://</literal>, or <literal>svn://</literal>) is used
         to determine which RA module will handle the communications.
         Each module registers a list of the protocols it knows how to
         <quote>speak</quote> so that the RA loader can, at runtime,

Modified: trunk/src/en/book/ch-fundamental-concepts.xml
--- trunk/src/en/book/ch-fundamental-concepts.xml	(original)
+++ trunk/src/en/book/ch-fundamental-concepts.xml	Fri Feb 23 01:19:38 2007
@@ -315,7 +315,7 @@
       <para>But there are some nuances in Subversion's handling of URLs
         that are notable.  For example, URLs containing the
-        <literal>file:</literal> access method (used for local
+        <literal>file://</literal> access method (used for local
         repositories) must, in accordance with convention, have either a
         server name of <literal>localhost</literal> or no server name at
@@ -327,7 +327,7 @@
-      <para>Also, users of the <literal>file:</literal> scheme on
+      <para>Also, users of the <literal>file://</literal> scheme on
         Windows platforms will need to use an unofficially
         <quote>standard</quote> syntax for accessing repositories
         that are on the same machine, but on a different drive than
@@ -349,10 +349,10 @@
         (non-URL) form of a path on Windows uses backslashes.</para>
-        <para>Subversion's <literal>file:</literal> URLs cannot be
+        <para>Subversion's <literal>file://</literal> URLs cannot be
           used in a regular web browser the way typical
-          <literal>file:</literal> URLs can.  When you attempt to view
-          a <literal>file:</literal> URL in a regular web browser, it
+          <literal>file://</literal> URLs can.  When you attempt to view
+          a <literal>file://</literal> URL in a regular web browser, it
           reads and displays the contents of the file at that location
           by examining the filesystem directly.  However, Subversion's
           resources exist in a virtual filesystem (see <xref

Modified: trunk/src/en/book/ch-repository-admin.xml
--- trunk/src/en/book/ch-repository-admin.xml	(original)
+++ trunk/src/en/book/ch-repository-admin.xml	Fri Feb 23 01:19:38 2007
@@ -628,7 +628,7 @@
           as one user—such as Apache's <command>httpd</command>
           or <command>svnserve</command> (see <xref
           linkend="svn.serverconfig"/>)—rather than accessing it
-          as many different users via <literal>file:///</literal> or
+          as many different users via <literal>file://</literal> or
           <literal>svn+ssh://</literal> URLs.  If using a Berkeley DB
           repository directly as multiple users, be sure to read <xref
@@ -769,7 +769,7 @@
           repository, and are in fact unable to perform tasks across a
           network.  A common mistake made by Subversion newcomers is
           trying to pass URLs (even <quote>local</quote>
-          <literal>file:</literal> ones) to these two programs.</para>
+          <literal>file://</literal> ones) to these two programs.</para>
       <para>Present in the <filename>db/</filename> subdirectory of

Modified: trunk/src/en/book/ch-server-configuration.xml
--- trunk/src/en/book/ch-server-configuration.xml	(original)
+++ trunk/src/en/book/ch-server-configuration.xml	Fri Feb 23 01:19:38 2007
@@ -374,7 +374,7 @@
           <para>Do <emphasis>not</emphasis> be seduced by the simple
             idea of having all of your users access a repository
-            directly via <literal>file:///</literal> URLs.  Even if
+            directly via <literal>file://</literal> URLs.  Even if
             the repository is readily available to everyone via
             network share, this is a bad idea.  It removes any layers
             of protection between the users and the repository: users
@@ -387,7 +387,7 @@
             accessing repositories via <literal>svn+ssh://</literal>
             URLs — from a security standpoint, it's effectively
             the same as local users accessing
-            via <literal>file:///</literal>, and can entail all the
+            via <literal>file://</literal>, and can entail all the
             same problems if the administrator isn't careful.</para>
@@ -548,7 +548,7 @@
           agent like this, be sure that the authenticated user has
           full read and write access to the repository database files.
           It's essentially the same as a local user accessing the
-          repository via <literal>file:///</literal> URLs.</para>
+          repository via <literal>file://</literal> URLs.</para>
         <para>This option is described in much more detail in
           <xref linkend="svn.serverconfig.svnserve.sshauth"/>.</para>
@@ -891,7 +891,7 @@
         controlled by operating system permissions to the repository's
         database files; it's very much the same as if Harry were
         accessing the repository directly via a
-        <literal>file:///</literal> URL.  If multiple system users are
+        <literal>file://</literal> URL.  If multiple system users are
         going to be accessing the repository directly, you may want to
         place them into a common group, and you'll need to be careful
         about umasks.  (Be sure to read <xref
@@ -2540,7 +2540,7 @@
         <para>regular system users using a Subversion client (as
           themselves) to access the repository directly via
-          <literal>file:///</literal> URLs;</para>
+          <literal>file://</literal> URLs;</para>
         <para>regular system users connecting to SSH-spawned private

More information about the svnbook-dev mailing list