[svnbook] r4418 committed - * en/book/appc-webdav.xml,...

svnbook at googlecode.com svnbook at googlecode.com
Fri Feb 8 12:33:07 CST 2013


Revision: 4418
Author:   cmpilato at gmail.com
Date:     Fri Feb  8 10:32:43 2013
Log:      * en/book/appc-webdav.xml,
* en/book/ch00-preface.xml,
* en/book/ch01-fundamental-concepts.xml,
* en/book/ch02-basic-usage.xml,
* en/book/ch03-advanced-topics.xml,
* en/book/ch04-branching-and-merging.xml,
* en/book/ch05-repository-admin.xml,
* en/book/ch06-server-configuration.xml,
* en/book/ch07-customizing-svn.xml,
* en/book/ch08-embedding-svn.xml,
* en/book/ref-reposhooks.xml
   Still more indexing work.

SIDEBAR: This work is painful.  You're constantly re-shuffling and
re-categorizing stuff. Folks that do this kind of thing day in and day
out probably go insane within a month's time.

http://code.google.com/p/svnbook/source/detail?r=4418

Modified:
  /trunk/en/book/appc-webdav.xml
  /trunk/en/book/ch00-preface.xml
  /trunk/en/book/ch01-fundamental-concepts.xml
  /trunk/en/book/ch02-basic-usage.xml
  /trunk/en/book/ch03-advanced-topics.xml
  /trunk/en/book/ch04-branching-and-merging.xml
  /trunk/en/book/ch05-repository-admin.xml
  /trunk/en/book/ch06-server-configuration.xml
  /trunk/en/book/ch07-customizing-svn.xml
  /trunk/en/book/ch08-embedding-svn.xml
  /trunk/en/book/ref-reposhooks.xml

=======================================
--- /trunk/en/book/appc-webdav.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/appc-webdav.xml	Fri Feb  8 10:32:43 2013
@@ -3,11 +3,11 @@
  <appendix id="svn.webdav">
    <title>WebDAV and Autoversioning</title>

-  <para>WebDAV is an extension to HTTP, and it is growing more and more
-    popular as a standard for file sharing.  Today's operating systems
-    are becoming extremely web-aware, and many now have built-in
-    support for mounting <quote>shares</quote> exported by WebDAV
-    servers.</para>
+  <para>WebDAV is an extension to HTTP, and it is growing more
+    and more popular as a standard for file sharing.  Today's
+    operating systems are becoming extremely web-aware, and many now
+    have built-in support for mounting <quote>shares</quote> exported
+    by WebDAV servers.</para>

    <para>If you use Apache as your Subversion network server, to
      some extent you are also running a WebDAV server.  This appendix
@@ -22,14 +22,17 @@
    <sect1 id="svn.webdav.basic">
      <title>What Is WebDAV?</title>

-    <para><firstterm>DAV</firstterm> stands for <quote>Distributed
-      Authoring and Versioning.</quote>  RFC 2518 defines a set of
-      concepts and accompanying extension methods to HTTP 1.1 that
-      make the Web a more universal read/write medium.  The basic
-      idea is that a WebDAV-compliant web server can act like a
-      generic file server; clients can <quote>mount</quote> shared
-      folders over HTTP that behave much like other network
-      filesystems (such as NFS or SMB).</para>
+    <para>
+      <indexterm>
+        <primary>WebDAV</primary>
+      </indexterm><firstterm>DAV</firstterm> stands
+      for <quote>Distributed Authoring and Versioning.</quote> RFC
+      2518 defines a set of concepts and accompanying extension
+      methods to HTTP 1.1 that make the Web a more universal
+      read/write medium.  The basic idea is that a WebDAV-compliant
+      web server can act like a generic file server; clients
+      can <quote>mount</quote> shared folders over HTTP that behave
+      much like other network filesystems (such as NFS or SMB).</para>

      <para>The tragedy, though, is that despite the acronym, the RFC
        specification doesn't actually describe any sort of version
@@ -118,7 +121,11 @@
    <sect1 id="svn.webdav.autoversioning">
      <title>Autoversioning</title>

-    <para>While the Subversion client is not a full DeltaV client, and
+    <para>
+      <indexterm>
+        <primary>WebDAV</primary>
+        <secondary>autoversioning</secondary>
+      </indexterm>While the Subversion client is not a full DeltaV client,  
and
        the Subversion server is not a full DeltaV server, there's still a
        glimmer of WebDAV interoperability to be happy about:
        <firstterm>autoversioning</firstterm>.</para>
@@ -237,7 +244,11 @@
    <sect1 id="svn.webdav.clients">
      <title>Client Interoperability</title>

-    <para>All WebDAV clients fall into one of three
+    <para>
+      <indexterm>
+        <primary>WebDAV</primary>
+        <secondary>client support</secondary>
+      </indexterm>All WebDAV clients fall into one of three
        categories—standalone applications, file-explorer
        extensions, or filesystem implementations.  These categories
        broadly define the types of WebDAV functionality available to
=======================================
--- /trunk/en/book/ch00-preface.xml	Fri Feb  8 08:09:53 2013
+++ /trunk/en/book/ch00-preface.xml	Fri Feb  8 10:32:43 2013
@@ -63,11 +63,11 @@
          <primary>Subversion</primary>
        </indexterm>
        <indexterm>
-        <primary>version control system</primary>
+        <primary>version control systems</primary>
        </indexterm>
        <indexterm>
          <primary>VCS</primary>
-        <see>version control system</see>
+        <see>version control systems</see>
        </indexterm>Subversion is a free/open source <firstterm>version
        control system</firstterm> (VCS).  That is, Subversion manages
        files and directories, and the changes made to them, over time.
@@ -163,7 +163,8 @@

        <para>
          <indexterm>
-          <primary>centralized version control</primary>
+          <primary>version control systems</primary>
+          <secondary>centralized</secondary>
          </indexterm>Once you've decided that you need a version
          control solution, you'll find no shortage of available
          options.  When Subversion was first designed and released, the
@@ -179,14 +180,12 @@

        <para>
          <indexterm>
-          <primary>changesets</primary>
-        </indexterm>
-        <indexterm>
-          <primary>distributed version control</primary>
+          <primary>version control systems</primary>
+          <secondary>distributed</secondary>
          </indexterm>
          <indexterm>
            <primary>DVCS</primary>
-          <see>distributed version control</see>
+          <see>version control systems, distributed</see>
          </indexterm>Much as changed since that time, though.  In the
          years since the Subversion project began its life, a newer
          methodology of version control called <firstterm>distributed
@@ -203,13 +202,12 @@
          Rather, each user keeps and operates against very
          deep—complete, in a sense—local version history
          data stores.  Collaboration still occurs, but is accomplished
-        by trading <firstterm>changesets</firstterm> (collections of
-        changes made to versioned items) directly between users' local
-        data stores, not via a centralized master data store.  In
-        fact, any semblance of a canonical <quote>master</quote>
-        source of a project's versioned data is by convention only, a
-        status attributed by the various collaborators on that
-        project.</para>
+        by trading collections of changes made to versioned items
+        directly between users' local data stores, not via a
+        centralized master data store.  In fact, any semblance of a
+        canonical <quote>master</quote> source of a project's
+        versioned data is by convention only, a status attributed by
+        the various collaborators on that project.</para>

        <para>There are pros and cons to each version control approach.
          Perhaps the two biggest benefits delivered by the DVCS tools
=======================================
--- /trunk/en/book/ch01-fundamental-concepts.xml	Fri Feb  8 08:09:53 2013
+++ /trunk/en/book/ch01-fundamental-concepts.xml	Fri Feb  8 10:32:43 2013
@@ -23,7 +23,7 @@

      <para>
        <indexterm>
-        <primary>version control system</primary>
+        <primary>version control systems</primary>
        </indexterm>A version control system (or revision control
        system) is a system that tracks incremental versions (or
        revisions) of files and, in some cases, directories over time.
@@ -47,14 +47,14 @@

        <para>
          <indexterm>
-          <primary>repository</primary>
+          <primary>repositories</primary>
          </indexterm>
          <indexterm>
-          <primary>repository</primary>
+          <primary>repositories</primary>
            <secondary>filesystem tree</secondary>
          </indexterm>
          <indexterm>
-          <primary>version control system</primary>
+          <primary>version control systems</primary>
            <secondary>clients</secondary>
          </indexterm>At the core of the version control system is a
          repository, which is the central store of that system's data.
@@ -316,7 +316,7 @@

          <para>
            <indexterm>
-            <primary>conflict</primary>
+            <primary>conflicts</primary>
            </indexterm>But what if Sally's changes
            <emphasis>do</emphasis> overlap with Harry's changes?  What
            then?  This situation is called a
@@ -427,7 +427,7 @@

        <para>
          <indexterm>
-          <primary>revision</primary>
+          <primary>revisions</primary>
          </indexterm>Each time the repository accepts a commit, this
          creates a new state of the filesystem tree, called a
          <firstterm>revision</firstterm>.  Each revision is assigned a
@@ -453,7 +453,7 @@

          <para>
            <indexterm>
-            <primary>revision</primary>
+            <primary>revisions</primary>
              <secondary>global</secondary>
            </indexterm>Unlike most version control systems,
            Subversion's revision numbers apply to <emphasis>the entire
@@ -481,24 +481,7 @@

        <para>
          <indexterm>
-          <primary>svn</primary>
-          <secondary>syntax</secondary>
-          <tertiary>URLs</tertiary>
-        </indexterm>
-        <indexterm>
-          <primary>svnmucc</primary>
-          <secondary>syntax</secondary>
-          <tertiary>URLs</tertiary>
-        </indexterm>
-        <indexterm>
-          <primary>svnsync</primary>
-          <secondary>syntax</secondary>
-          <tertiary>URLs</tertiary>
-        </indexterm>
-        <indexterm>
-          <primary>svnrdump</primary>
-          <secondary>syntax</secondary>
-          <tertiary>URLs</tertiary>
+          <primary>repository URL</primary>
          </indexterm>Subversion client programs use URLs to identify
          versioned files and directories in Subversion repositories.
          For the most part, these URLs use the standard syntax,
@@ -743,7 +726,7 @@

          <itemizedlist>
            <indexterm>
-            <primary>revision</primary>
+            <primary>revisions</primary>
              <secondary>working</secondary>
            </indexterm>

=======================================
--- /trunk/en/book/ch02-basic-usage.xml	Fri Feb  8 08:09:53 2013
+++ /trunk/en/book/ch02-basic-usage.xml	Fri Feb  8 10:32:43 2013
@@ -1068,8 +1068,8 @@
              <tertiary>diff</tertiary>
            </indexterm>
            <indexterm>
-            <primary>diff</primary>
-            <secondary>unified</secondary>
+            <primary>differences</primary>
+            <secondary>unified diff</secondary>
            </indexterm>Another way to examine your changes is with the
            <command>svn diff</command> command, which displays
            differences in file content.  When you run <userinput>svn
@@ -1140,11 +1140,11 @@
              <tertiary>patch</tertiary>
            </indexterm>
            <indexterm>
-            <primary>patch</primary>
+            <primary>patches</primary>
            </indexterm>
            <indexterm>
              <primary>patch file</primary>
-            <see>patch</see>
+            <see>patches</see>
            </indexterm>The <command>svn diff</command> command produces this
            output by comparing your working files against its pristine
            text-base.  Files scheduled for addition are displayed as
@@ -1284,12 +1284,11 @@
      <sect2 id="svn.tour.cycle.resolve">
        <title>Resolve Any Conflicts</title>

-      <indexterm>
-        <primary>conflict</primary>
-        <secondary>resolving</secondary>
-      </indexterm>
-
-      <para>We've already seen how <userinput>svn status
+      <para>
+        <indexterm>
+          <primary>conflicts</primary>
+          <secondary>resolving</secondary>
+        </indexterm>We've already seen how <userinput>svn status
          -u</userinput> can predict conflicts, but dealing with those
          conflicts is still something that remains to be done.
          Conflicts can occur any time you attempt to merge or integrate
@@ -1298,9 +1297,9 @@
          update</command> creates exactly that sort of
          scenario—that command's very purpose is to bring your
          working copy up to date with the repository by merging all the
-        changes made since your last update into your working
-        copy.  So how does Subversion report these conflicts to you,
-        and how do you deal with them?</para>
+        changes made since your last update into your working copy.
+        So how does Subversion report these conflicts to you, and how
+        do you deal with them?</para>

        <para>Suppose you run <userinput>svn update</userinput> and you
          see this sort of interesting output:</para>
@@ -1485,16 +1484,15 @@

          <title>Viewing conflict differences interactively</title>

-        <indexterm>
-          <primary>conflict</primary>
-          <secondary>reviewing</secondary>
-        </indexterm>
-
-        <para>Before deciding how to attack a conflict interactively,
-          odds are that you'd like to see exactly what is in conflict.
-          Two of the commands available at the interactive conflict
-          resolution prompt can assist you here.  The first is
-          the <quote>diff-full</quote> command
+        <para>
+          <indexterm>
+            <primary>conflicts</primary>
+            <secondary>reviewing</secondary>
+          </indexterm>Before deciding how to attack a conflict
+          interactively, odds are that you'd like to see exactly what
+          is in conflict.  Two of the commands available at the
+          interactive conflict resolution prompt can assist you here.
+          The first is the <quote>diff-full</quote> command
            (<userinput>df</userinput>), which displays all the local
            modifications to the file in question plus any conflict
            regions:</para>
@@ -1548,9 +1546,8 @@
          <title>Resolving conflict differences interactively</title>

          <indexterm>
-          <primary>conflict</primary>
-          <secondary>resolution</secondary>
-          <tertiary>interactive</tertiary>
+          <primary>hook scripts</primary>
+          <secondary>interactive</secondary>
          </indexterm>

          <para>There are several different ways to resolve conflicts
@@ -1609,9 +1606,8 @@
          <title>Postponing conflict resolution</title>

          <indexterm>
-          <primary>conflict</primary>
-          <secondary>resolution</secondary>
-          <tertiary>postponing</tertiary>
+          <primary>hook scripts</primary>
+          <secondary>postponing</secondary>
          </indexterm>

          <para>This may sound like an appropriate section for avoiding
@@ -1638,7 +1634,7 @@
          <itemizedlist>

            <indexterm>
-            <primary>conflict</primary>
+            <primary>conflicts</primary>
              <secondary>conflict markers</secondary>
            </indexterm>

@@ -1818,9 +1814,8 @@
          <title>Manual conflict resolution</title>

          <indexterm>
-          <primary>conflict</primary>
-          <secondary>resolution</secondary>
-          <tertiary>manual</tertiary>
+          <primary>hook scripts</primary>
+          <secondary>manual</secondary>
          </indexterm>

          <para>Manually resolving conflicts can be quite intimidating the
@@ -1943,15 +1938,14 @@
        <sect3 id="svn.tour.cycle.resolve.theirsfull">
          <title>Discarding your changes in favor of a newly fetched
            revision</title>
-
-        <indexterm>
-          <primary>conflict</primary>
-          <secondary>resolution</secondary>
-        </indexterm>

-        <para>If you get a conflict and decide that you want to throw
-          out your changes, you can run <userinput>svn resolve
-          --accept theirs-full
+        <para>
+          <indexterm>
+            <primary>conflicts</primary>
+            <secondary>resolution</secondary>
+          </indexterm>If you get a conflict and decide that you want
+          to throw out your changes, you can run <userinput>svn
+          resolve --accept theirs-full
            <replaceable>CONFLICTED-PATH</replaceable></userinput> and
            Subversion will discard your edits and remove the temporary
            files:</para>
@@ -2916,12 +2910,12 @@

      <para>
        <indexterm>
-        <primary>tree conflict</primary>
+        <primary>tree conflicts</primary>
        </indexterm>
        <indexterm>
-        <primary>conflict</primary>
+        <primary>conflicts</primary>
          <secondary>tree</secondary>
-        <see>tree conflict</see>
+        <see>tree conflicts</see>
        </indexterm>But what happens if your collaborators move or
        delete a file that you are still working on?  Maybe there was a
        miscommunication, and one person thinks the file should be
=======================================
--- /trunk/en/book/ch03-advanced-topics.xml	Fri Feb  8 08:09:53 2013
+++ /trunk/en/book/ch03-advanced-topics.xml	Fri Feb  8 10:32:43 2013
@@ -63,7 +63,7 @@

      <para>
        <indexterm>
-        <primary>revision</primary>
+        <primary>revisions</primary>
          <secondary>keywords</secondary>
        </indexterm>But occasionally, you need to pinpoint a moment in
        time for which you don't already have a revision number
@@ -411,20 +411,15 @@

      <para>
        <indexterm>
-        <primary>revision</primary>
-        <secondary>peg revision</secondary>
+        <primary>revisions</primary>
+        <secondary>peg revisions</secondary>
        </indexterm>
        <indexterm>
          <primary>at syntax</primary>
-        <see>syntax, at syntax</see>
        </indexterm>
        <indexterm>
          <primary>@</primary>
          <see>syntax, at syntax</see>
-      </indexterm>
-      <indexterm>
-        <primary>syntax</primary>
-        <secondary>at syntax</secondary>
        </indexterm>Fortunately, Subversion allows you to tell it
        exactly which Main Street you meant.  The mechanism used is
        called a <firstterm>peg revision</firstterm>, and you provide
@@ -441,11 +436,11 @@

      <para>
        <indexterm>
-        <primary>revision</primary>
-        <secondary>operative revision</secondary>
+        <primary>revisions</primary>
+        <secondary>operative revisions</secondary>
        </indexterm>
        <indexterm>
-        <primary>revision</primary>
+        <primary>revisions</primary>
          <secondary>operative revision range</secondary>
        </indexterm>But what of the <option>--revision</option>
        (<option>-r</option>) of which we've spoken so much in this
@@ -2442,8 +2437,8 @@
            <primary>line endings</primary>
          </indexterm>
          <indexterm>
-          <primary>end-of-line (EOL)</primary>
-          <see>line endings, defined</see>
+          <primary>end-of-line (EOL) markers</primary>
+          <see>line endings</see>
          </indexterm>This means that by default, Subversion doesn't pay
          any attention to the type of <firstterm>end-of-line (EOL)
          markers</firstterm> used in your files.  Unfortunately,
=======================================
--- /trunk/en/book/ch04-branching-and-merging.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ch04-branching-and-merging.xml	Fri Feb  8 10:32:43 2013
@@ -44,8 +44,7 @@
      <para>
        <indexterm>
          <primary>branches</primary>
-      </indexterm>
-      This is the basic concept of a branch—namely,
+      </indexterm>This is the basic concept of a branch—namely,
        a line of development that exists independently of another line,
        yet still shares a common history if you look far enough back in
        time.  A branch always begins life as a copy of something, and
@@ -170,12 +169,26 @@
          which begins its life as a copy
          of <filename>/calc/trunk</filename>.</para>

-      <para>You may already have seen <command>svn copy</command> used
-        to copy one file to another within a working copy.  But it can
-        also be used to do a <firstterm>remote
-        copy</firstterm>—a copy that immediately results in a
-        newly committed repository revision and for which no working
-        copy is required at all.  Just copy one URL to another:</para>
+      <para>
+        <indexterm>
+          <primary>copying</primary>
+          <secondary>remote copies</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>svn</primary>
+          <secondary>subcommands</secondary>
+          <tertiary>copy</tertiary>
+        </indexterm>
+        <indexterm>
+          <primary>branches</primary>
+          <secondary>creating</secondary>
+        </indexterm>You may already have seen <command>svn
+        copy</command> used to copy one file to another within a
+        working copy.  But it can also be used to do
+        a <firstterm>remote copy</firstterm>—a copy that
+        immediately results in a newly committed repository revision
+        and for which no working copy is required at all.  Just copy
+        one URL to another:</para>

        <informalexample>
          <screen>
@@ -454,7 +467,10 @@
        near-impossible to merge your changes back into the trunk
        without a huge number of conflicts.</para>

-    <para>Instead, you and Sally might continue to share changes as
+    <para>
+      <indexterm>
+        <primary>merging</primary>
+      </indexterm>Instead, you and Sally might continue to share changes as
        you work.  It's up to you to decide which changes are worth
        sharing; Subversion gives you the ability to selectively
        <quote>copy</quote> changes between branches.  And when you're
@@ -484,8 +500,7 @@
        <para>
          <indexterm>
            <primary>merge tracking</primary>
-        </indexterm>
-        Subversion 1.5 introduced the
+        </indexterm>Subversion 1.5 introduced the
          <firstterm>merge tracking</firstterm> feature to Subversion.
          Prior to this feature keeping track of merges required cumbersome
          manual procedures or the use of external tools. Subsequent
@@ -502,7 +517,10 @@
      <sect2 id="svn.branchmerge.changesets">
        <title>Changesets</title>

-      <para>Before we proceed further, we should warn you that there's
+      <para>
+        <indexterm>
+          <primary>changesets</primary>
+        </indexterm>Before we proceed further, we should warn you that  
there's
          a lot of discussion of <quote>changes</quote> in
          the pages ahead.  A lot of people experienced with version
          control systems use the terms <quote>change</quote>
@@ -549,11 +567,20 @@
      <sect2 id="svn.branchmerge.basicmerging.stayinsync">
        <title>Keeping a Branch in Sync</title>

-      <para>Continuing with our running example, let's suppose that a
-        week has passed since you started working on your private
-        branch.  Your new feature isn't finished yet, but at the same
-        time you know that other people on your team continue to make
-        important changes in the
+      <para>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>sync merges</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>svn</primary>
+          <secondary>subcommands</secondary>
+          <tertiary>merge</tertiary>
+        </indexterm>Continuing with our running example, let's suppose
+        that a week has passed since you started working on your
+        private branch.  Your new feature isn't finished yet, but at
+        the same time you know that other people on your team continue
+        to make important changes in the
          project's <filename>/trunk</filename>.  It's in your best
          interest to replicate those changes to your own branch, just
          to make sure they mesh well with your changes.  This is done
@@ -591,7 +618,11 @@
  </screen>
        </informalexample>

-      <para>This basic syntax—<userinput>svn merge
+      <para>
+        <indexterm>
+          <primary>properties</primary>
+          <secondary>svn:mergeinfo</secondary>
+        </indexterm>This basic syntax—<userinput>svn merge
          <replaceable>URL</replaceable></userinput>—tells
          Subversion to merge all changes which have not been previously
          merged from the URL to the current working directory (which is
@@ -611,11 +642,11 @@
          <para>
            <indexterm>
              <primary>mergeinfo</primary>
-          </indexterm>
-          In this book and elsewhere (Subversion mailing lists, articles
-          on merge tracking, etc.) you will frequently come across the
-          term <firstterm>mergeinfo</firstterm>. This is simply shorthand
-          for the <literal>svn:mergeinfo</literal> property.</para>
+          </indexterm>In this book and elsewhere (Subversion mailing
+          lists, articles on merge tracking, etc.) you will frequently
+          come across the term <firstterm>mergeinfo</firstterm>. This
+          is simply shorthand for the <literal>svn:mergeinfo</literal>
+          property.</para>
        </tip>

        <sidebar>
@@ -878,18 +909,19 @@
          <title>Subtree Merges and Subtree Mergeinfo</title>
          <para>
            <indexterm>
-            <primary>subtree merge</primary>
+            <primary>merging</primary>
+            <secondary>subtree merge</secondary>
            </indexterm>
            <indexterm>
-            <primary>subtree mergeinfo</primary>
-          </indexterm>
-          In most of the examples in this chapter the merge target is
-          the root directory of a branch (see
+            <primary>mergeinfo</primary>
+            <secondary>subtree mergeinfo</secondary>
+          </indexterm>In most of the examples in this chapter the
+          merge target is the root directory of a branch (see
            <xref linkend="svn.branchmerge.whatis"/>). While this is a
-          best practice, you may occasionally need to merge directly to
-          some child of the branch root. This type of merge is called a
-          <firstterm>subtree merge</firstterm> and the mergeinfo recorded
-          to describe it is called
+          best practice, you may occasionally need to merge directly
+          to some child of the branch root. This type of merge is
+          called a <firstterm>subtree merge</firstterm> and the
+          mergeinfo recorded to describe it is called
            <firstterm>subtree mergeinfo</firstterm>. There is nothing
            special about subtree merges or subtree mergeinfo.  In fact
            there is really only one important point to keep in mind
@@ -953,14 +985,15 @@
  </screen>
          </informalexample>

-        <indexterm>
-          <primary>mergeinfo elision</primary>
-        </indexterm>
-
-        <para>You might be wondering why <filename>INSTALL</filename>
-          in the above example has mergeinfo for r651-652, when we
-          only merged r958. This is due to mergeinfo inheritance,
-          which we'll cover in the sidebar
+        <para>
+          <indexterm>
+            <primary>mergeinfo</primary>
+            <secondary>elision</secondary>
+          </indexterm>You might be wondering
+          why <filename>INSTALL</filename> in the above example has
+          mergeinfo for r651-652, when we only merged r958. This is
+          due to mergeinfo inheritance, which we'll cover in the
+          sidebar
            <xref  
linkend="svn.branchmerge.basicmerging.mergeinfo.inheritance"
            />.  Also note that the subtree mergeinfo on
            <filename>doc/INSTALL</filename> was removed, or
@@ -1291,17 +1324,21 @@
        <sidebar id="svn.branchmerge.basicmerging.mergeinfo.inheritance">
          <title>Mergeinfo Inheritance</title>

-        <indexterm>
-          <primary>mergeinfo inheritance</primary>
-        </indexterm>
-
-        <para>When a path has the <literal>svn:mergeinfo</literal>
-          property set on it we say it has <firstterm>explicit
-          mergeinfo</firstterm>.  This explicit mergeinfo describes
-          not only what changes were merged into that particular
-          directory, but also all the children of that directory
-          (because those children inherit the mergeinfo of their
-          parent path).  For example:</para>
+        <para>
+          <indexterm>
+            <primary>mergeinfo</primary>
+            <secondary>inheritance</secondary>
+          </indexterm>
+          <indexterm>
+            <primary>mergeinfo</primary>
+            <secondary>explicit</secondary>
+          </indexterm>When a path has
+          the <literal>svn:mergeinfo</literal> property set on it we
+          say it has <firstterm>explicit mergeinfo</firstterm>.  This
+          explicit mergeinfo describes not only what changes were
+          merged into that particular directory, but also all the
+          children of that directory (because those children inherit
+          the mergeinfo of their parent path).  For example:</para>

          <informalexample>
            <screen>
@@ -1750,7 +1787,11 @@
      <sect2 id="svn.branchmerge.cherrypicking">
        <title>Cherrypicking</title>

-      <para>Just as the term <quote>changeset</quote> is often used in
+      <para>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>cherrypicking</secondary>
+        </indexterm>Just as the term <quote>changeset</quote> is often  
used in
          version control systems, so is the term
          <firstterm>cherrypicking</firstterm>.  This word refers to
          the act of choosing <emphasis>one</emphasis> specific
@@ -1855,7 +1896,11 @@
  </screen>
        </informalexample>

-      <para>This use case of replicating
+      <para>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>backporting</secondary>
+        </indexterm>This use case of replicating
          (or <firstterm>backporting</firstterm>) bug fixes from one
          branch to another is perhaps the most popular reason for
          cherrypicking changes; it comes up all the time, for example,
@@ -1965,6 +2010,19 @@
          arguments:</para>

        <orderedlist>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>left side</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>right side</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>target</secondary>
+        </indexterm>
+
          <listitem>
            <para>An initial repository tree (often called the
              <firstterm>left side</firstterm> of the comparison)</para>
@@ -2105,7 +2163,15 @@
        <sidebar id="svn.branchmerge.nomergedata.impicit.mergeinfo">
          <title>Natural History and Implicit Mergeinfo</title>

-        <para>As we mentioned earlier when discussing
+        <para>
+          <indexterm>
+            <primary>mergeinfo</primary>
+            <secondary>implicit</secondary>
+          </indexterm>
+          <indexterm>
+            <primary>natural history</primary>
+            <see>mergeinfo, implicit</see>
+          </indexterm>As we mentioned earlier when discussing
            <xref  
linkend="svn.branchmerge.basicmerging.mergeinfo.inheritance"/>,
            a path that has the
            <literal>svn:mergeinfo</literal> property set on it is said to
@@ -2667,9 +2733,8 @@
        <para>
          <indexterm>
            <primary>ancestry</primary>
-        </indexterm>
-        When conversing with a Subversion developer, you might
-        very likely hear reference to the term
+        </indexterm>When conversing with a Subversion developer, you
+        might very likely hear reference to the term
          <firstterm>ancestry</firstterm>.  This word is used to
          describe the relationship between two objects in a
          repository: if they're related to each other, one
@@ -3582,7 +3647,11 @@
      <sect2 id="svn.branchmerge.commonpatterns.feature">
        <title>Feature Branches</title>

-      <para>A <firstterm>feature branch</firstterm> is the sort of
+      <para>
+        <indexterm>
+          <primary>branches</primary>
+          <secondary>feature branches</secondary>
+        </indexterm>A <firstterm>feature branch</firstterm> is the sort of
          branch that's been the dominant example in this chapter (the
          one you've been working on while Sally continues to work on
          <filename>/trunk</filename>).  It's a temporary branch created
@@ -3680,7 +3749,15 @@
    <sect1 id="svn.advanced.vendorbr">
      <title>Vendor Branches</title>

-    <para>As is especially the case when developing software, the data
+    <para>
+      <indexterm>
+        <primary>branches</primary>
+        <secondary>vendor branches</secondary>
+      </indexterm>
+      <indexterm>
+        <primary>branches</primary>
+        <secondary>vendor branches</secondary>
+      </indexterm>As is especially the case when developing software, the  
data
        that you maintain under version control is often closely related
        to, or perhaps dependent upon, someone else's data.  Generally,
        the needs of your project will dictate that you stay as
@@ -3735,12 +3812,16 @@
        necessitating regeneration of those changes with each successive
        version of the third-party code that you track.</para>

-    <para>The solution to this problem is to use <firstterm>vendor
-      branches</firstterm>.  A vendor branch is a directory tree in
-      your own version control system that contains information
-      provided by a third-party entity, or vendor.  Each version of
-      the vendor's data that you decide to absorb into your project is
-      called a <firstterm>vendor drop</firstterm>.</para>
+    <para>
+      <indexterm>
+        <primary>vendor drop</primary>
+      </indexterm>The solution to this problem is to
+      use <firstterm>vendor branches</firstterm>.  A vendor branch is
+      a directory tree in your own version control system that
+      contains information provided by a third-party entity, or
+      vendor.  Each version of the vendor's data that you decide to
+      absorb into your project is called a <firstterm>vendor
+      drop</firstterm>.</para>

      <para>Vendor branches provide two benefits.  First, by storing the
        currently supported vendor drop in your own version control
@@ -3824,18 +3905,34 @@
          procedures which include the creation of tags for each stable
          release version.</para>

-      <para>Since Subversion 1.5, <command>svn merge</command> has
-        been able to perform so-called <firstterm>foreign repository
-        merges</firstterm>, where the sources of the merge live in a
-        different repository than the repository from which the merge
-        target working copy was checked out.  And in Subversion 1.8,
-        the behavior of <command>svn copy</command> was changed so
-        that when you perform a copy from a foreign repository into an
-        existing working copy, the resulting tree is incorporated into
-        that working copy and scheduled for addition.  It's
-        this <firstterm>foreign repository copy</firstterm>
-        functionality that we'll use to bootstrap our vendor
-        branch.</para>
+      <para>
+        <indexterm>
+          <primary>merging</primary>
+          <secondary>foreign repository merges</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>foreign repository merges</primary>
+          <see>merging, foreign repository merges</see>
+        </indexterm>
+        <indexterm>
+          <primary>copying</primary>
+          <secondary>foreign repository copies</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>foreign repository copies</primary>
+          <see>copying, foreign repository copies</see>
+        </indexterm>Since Subversion 1.5, <command>svn merge</command>
+        has been able to perform so-called <firstterm>foreign
+        repository merges</firstterm>, where the sources of the merge
+        live in a different repository than the repository from which
+        the merge target working copy was checked out.  And in
+        Subversion 1.8, the behavior of <command>svn copy</command>
+        was changed so that when you perform a copy from a foreign
+        repository into an existing working copy, the resulting tree
+        is incorporated into that working copy and scheduled for
+        addition.  It's this <firstterm>foreign repository
+        copy</firstterm> functionality that we'll use to bootstrap our
+        vendor branch.</para>

        <para>So let's create our vendor branch.  We'll begin by
          creating a placeholder directory for all such vendor branches
=======================================
--- /trunk/en/book/ch05-repository-admin.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ch05-repository-admin.xml	Fri Feb  8 10:32:43 2013
@@ -124,10 +124,15 @@
      </variablelist>

      <note>
-      <para>Prior to Subversion 1.5, the on-disk repository structure
-        also always contained a <filename>dav</filename> subdirectory.
-        <filename>mod_dav_svn</filename> used this directory to store
-        information about
+      <para>
+
+        <indexterm>
+          <primary>WebDAV</primary>
+          <secondary>activities</secondary>
+        </indexterm>Prior to Subversion 1.5, the on-disk repository
+        structure also always contained a <filename>dav</filename>
+        subdirectory. <filename>mod_dav_svn</filename> used this
+        directory to store information about
          WebDAV <firstterm>activities</firstterm>—mappings of
          high-level WebDAV protocol concepts to Subversion commit
          transactions.  Subversion 1.5 changed that behavior, moving
@@ -429,7 +434,21 @@
      <sect2 id="svn.reposadmin.basics.backends">
        <title>Choosing a Data Store</title>

-      <para>Subversion provides two options for the
+      <para>
+        <indexterm>
+          <primary>FSFS</primary>
+        </indexterm>
+        <indexterm>
+          <primary>Berkeley DB</primary>
+        </indexterm>
+        <indexterm>
+          <primary>BDB</primary>
+          <see>Berkeley DB</see>
+        </indexterm>
+        <indexterm>
+          <primary>repositories</primary>
+          <secondary>filesystem</secondary>
+        </indexterm>Subversion provides two options for the
          type of underlying data store—often referred to as
          <quote>the backend</quote> or, somewhat confusingly,
          <quote>the (versioned) filesystem</quote>—that each
@@ -567,7 +586,10 @@
        <sect3 id="svn.reposadmin.basics.backends.bdb">
          <title>Berkeley DB</title>

-        <para>When the initial design phase of Subversion was in
+        <para>
+          <indexterm>
+            <primary>Berkeley DB</primary>
+          </indexterm>When the initial design phase of Subversion was in
            progress, the developers decided to use Berkeley DB for a
            variety of reasons, including its open source license,
            transaction support, reliability, performance, API
@@ -698,7 +720,10 @@
        <sect3 id="svn.reposadmin.basics.backends.fsfs">
          <title>FSFS</title>

-        <para>In mid-2004, a second type of repository storage
+        <para>
+          <indexterm>
+            <primary>FSFS</primary>
+          </indexterm>In mid-2004, a second type of repository storage
            system—one that doesn't use a database at
            all—came into being.  An FSFS repository stores the
            changes associated with a revision in a single file, and so
@@ -727,17 +752,25 @@
              observed to cause performance problems on certain
              network-based filesystems.</para>

-          <para>Subversion 1.5 creates FSFS-backed repositories using
-            a slightly modified layout in which the contents of these
-            two directories are <firstterm>sharded</firstterm>, or
-            scattered across several subdirectories.  This can greatly
-            reduce the time it takes the system to locate any one of
-            these files, and therefore increases the overall
-            performance of Subversion when reading from the
-            repository.</para>
+          <para>
+            <indexterm>
+              <primary>FSFS</primary>
+              <secondary>sharding</secondary>
+            </indexterm>Subversion 1.5 creates FSFS-backed
+            repositories using a slightly modified layout in which the
+            contents of these two directories
+            are <firstterm>sharded</firstterm>, or scattered across
+            several subdirectories.  This can greatly reduce the time
+            it takes the system to locate any one of these files, and
+            therefore increases the overall performance of Subversion
+            when reading from the repository.</para>

-          <para>Subversion 1.6 and later takes the sharded layout one
-            step further, allowing administrators to
+          <para>
+            <indexterm>
+              <primary>FSFS</primary>
+              <secondary>packing</secondary>
+            </indexterm>Subversion 1.6 and later takes the sharded
+            layout one step further, allowing administrators to
              optionally <firstterm>pack</firstterm> each of their
              repository shards up into a single multi-revision file.
              This can have both performance and disk usage benefits.
@@ -893,12 +926,24 @@
      <sect2 id="svn.reposadmin.create.hooks">
        <title>Implementing Repository Hooks</title>

-      <para>A <firstterm>hook</firstterm> is a program triggered by
-        some repository event, such as the creation of a new revision
-        or the modification of an unversioned property.  Some hooks
-        (the so-called <quote>pre hooks</quote>) run in advance of a
-        repository operation and provide a means by which to both
-        report what is about to happen and prevent it from
+      <para>
+        <indexterm>
+          <primary>hook scripts</primary>
+        </indexterm>
+        <indexterm>
+          <primary>hooks</primary>
+          <see>hook scripts</see>
+        </indexterm>
+        <indexterm>
+          <primary>repositories</primary>
+          <secondary>hooks</secondary>
+          <see>hook scripts</see>
+        </indexterm>A <firstterm>hook</firstterm> is a program
+        triggered by some repository event, such as the creation of a
+        new revision or the modification of an unversioned property.
+        Some hooks (the so-called <quote>pre hooks</quote>) run in
+        advance of a repository operation and provide a means by which
+        to both report what is about to happen and prevent it from
          happening at all.  Other hooks (the <quote>post hooks</quote>)
          run after the completion of a repository event and are useful
          for performing tasks that examine—but don't
@@ -1106,7 +1151,10 @@
        <sect3 id="svn.reposadmin.maint.tk.svnadmin">
          <title>svnadmin</title>

-        <para>The <command>svnadmin</command> program is the
+        <para>
+          <indexterm>
+            <primary>svnadmin</primary>
+          </indexterm>The <command>svnadmin</command> program is the
            repository administrator's best friend.  Besides providing
            the ability to create Subversion repositories, this program
            allows you to perform several maintenance operations on
@@ -1143,7 +1191,21 @@
        <sect3 id="svn.reposadmin.maint.tk.svnlook">
          <title>svnlook</title>

-        <para><command>svnlook</command> is a tool provided by
+        <para>
+          <indexterm>
+            <primary>svnlook</primary>
+          </indexterm>
+          <indexterm>
+            <primary>revisions</primary>
+            <secondary>inspection</secondary>
+          </indexterm>
+          <indexterm>
+            <primary>transactions</primary>
+          </indexterm>
+          <indexterm>
+            <primary>transactions</primary>
+            <secondary>inspection</secondary>
+          </indexterm><command>svnlook</command> is a tool provided by
            Subversion for examining the various revisions and
            <firstterm>transactions</firstterm> (which are revisions
            in the making) in a repository.  No part of this program
@@ -1552,7 +1614,10 @@
        <sect3 id="svn.reposadmin.maint.diskspace.deltas">
          <title>How Subversion saves disk space</title>

-        <para>To keep the repository small, Subversion uses
+        <para>
+          <indexterm>
+            <primary>deltification</primary>
+          </indexterm>To keep the repository small, Subversion uses
            <firstterm>deltification</firstterm> (or delta-based storage)
            within the repository itself.  Deltification involves
            encoding the representation of a chunk of data as a
@@ -1568,7 +1633,10 @@
            files—is stored at a much smaller size than the
            original full-text representation of that data.</para>

-        <para>While deltified storage has been a part of Subversion's
+        <para>
+          <indexterm>
+            <primary>representation sharing</primary>
+          </indexterm>While deltified storage has been a part of  
Subversion's
            design since the very beginning, there have been additional
            improvements made over the years.  Subversion repositories
            created with Subversion 1.4 or later benefit from
@@ -1994,7 +2062,27 @@
          call for all, or some subset, of that data to be copied or
          moved into another repository.</para>

-      <para>Subversion provides such functionality by way of
+      <para>
+        <indexterm>
+          <primary>repository dump streams</primary>
+        </indexterm>
+        <indexterm>
+          <primary>dump files</primary>
+          <see>repository dump streams</see>
+        </indexterm>
+        <indexterm>
+          <primary>svnadmin</primary>
+          <secondary>subcommands</secondary>
+          <tertiary>dump</tertiary>
+        </indexterm>
+        <indexterm>
+          <primary>svnadmin</primary>
+          <secondary>subcommands</secondary>
+          <tertiary>load</tertiary>
+        </indexterm>
+        <indexterm>
+          <primary>svnrdump</primary>
+        </indexterm>Subversion provides such functionality by way of
          <firstterm>repository dump streams</firstterm>.  A repository
          dump stream (often referred to as a <quote>dump file</quote>
          when stored as a file on disk) is a portable, flat file format
=======================================
--- /trunk/en/book/ch06-server-configuration.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ch06-server-configuration.xml	Fri Feb  8 10:32:43 2013
@@ -26,17 +26,31 @@

      <title>Overview</title>

-    <para>Subversion was designed with an abstract repository access layer.
-      This means that a repository can be programmatically accessed by
-      any sort of server process, and the client <quote>repository
-      access</quote> API allows programmers to write plug-ins that
-      speak relevant network protocols.  In theory, Subversion can use
-      an infinite number of network implementations.  In practice,
-      there are only two Subversion servers in widespread use today.</para>
+    <para>
+      <indexterm>
+        <primary>API</primary>
+        <secondary>layers</secondary>
+        <tertiary>Repository Access (RA) Layer</tertiary>
+      </indexterm>Subversion was designed with an abstract repository
+      access layer.  This means that a repository can be
+      programmatically accessed by any sort of server process, and the
+      client <quote>repository access</quote> API allows programmers
+      to write plug-ins that speak relevant network protocols.  In
+      theory, Subversion can use an infinite number of network
+      implementations.  In practice, there are only two Subversion
+      servers in widespread use today.</para>

-    <para>Apache is an extremely popular web server; using the
-      <command>mod_dav_svn</command> module, Apache can access a
-      repository and make it available to clients via the
+    <para>
+      <indexterm>
+        <primary>httpd</primary>
+      </indexterm>
+      <indexterm>
+        <primary>Apache HTTP Server</primary>
+        <see>httpd</see>
+      </indexterm>Apache HTTP Server (also known
+      as <command>httpd</command>) is an extremely popular web server;
+      using the <command>mod_dav_svn</command> module, Apache can
+      access a repository and make it available to clients via the
        WebDAV/DeltaV protocol, which is an extension of HTTP.  Because
        Apache is an extremely extensible server, it provides a number
        of features <quote>for free,</quote> such as encrypted SSL
@@ -44,16 +58,19 @@
        authentication systems, and limited built-in web browsing of
        repositories.</para>

-    <para>In the other corner is <command>svnserve</command>: a small,
-      lightweight server program that speaks a custom protocol with
-      clients.  Because its protocol is explicitly designed for
-      Subversion and is stateful (unlike HTTP), it provides
-      significantly faster network operations—but at the cost of
-      some features as well.  While it can use SASL to provide a
-      variety of authentication and encryption options, it has no
-      logging or built-in web browsing.  It is, however, extremely
-      easy to set up and is often the best option for small teams just
-      starting out with Subversion.</para>
+    <para>
+      <indexterm>
+        <primary>svnserve</primary>
+      </indexterm>In the other corner is <command>svnserve</command>:
+      a small, lightweight server program that speaks a custom
+      protocol with clients.  Because its protocol is explicitly
+      designed for Subversion and is stateful (unlike HTTP), it
+      provides significantly faster network operations—but at
+      the cost of some features as well.  While it can use SASL to
+      provide a variety of authentication and encryption options, it
+      has no logging or built-in web browsing.  It is, however,
+      extremely easy to set up and is often the best option for small
+      teams just starting out with Subversion.</para>

      <para>The network protocol which <command>svnserve</command>
        speaks may also be tunneled over an SSH connection.  This
@@ -439,7 +456,10 @@

      <title>svnserve, a Custom Server</title>

-    <para>The <command>svnserve</command> program is a lightweight
+    <para>
+      <indexterm>
+        <primary>svnserve</primary>
+      </indexterm>The <command>svnserve</command> program is a lightweight
        server, capable of speaking to clients over TCP/IP using a
        custom, stateful protocol.  Clients contact an
        <command>svnserve</command> server by using URLs that begin with
@@ -453,7 +473,11 @@
      <sect2 id="svn.serverconfig.svnserve.invoking">
        <title>Invoking the Server</title>

-      <para>There are a few different ways to run the
+      <para>
+        <indexterm>
+          <primary>svnserve</primary>
+          <secondary>running</secondary>
+        </indexterm>There are a few different ways to run the
          <command>svnserve</command> program:</para>

        <itemizedlist>
@@ -486,7 +510,12 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.daemon">
          <title>svnserve as daemon</title>

-        <para>The easiest option is to run <command>svnserve</command>
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>daemon mode</tertiary>
+          </indexterm>The easiest option is to run  
<command>svnserve</command>
            as a standalone <quote>daemon</quote> process.  Use the
            <option>-d</option> option for this:</para>

@@ -540,7 +569,15 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.inetd">
          <title>svnserve via inetd</title>

-        <para>If you want <command>inetd</command> to launch the
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>via inetd</tertiary>
+          </indexterm>
+          <indexterm>
+            <primary>inetd</primary>
+          </indexterm>If you want <command>inetd</command> to launch the
            process, you need to pass the <option>-i</option>
            (<option>--inetd</option>) option.  In the following
            example, we've shown the output from running
@@ -600,7 +637,15 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.xinetd">
          <title>svnserve via xinetd</title>

-        <para>Some operating systems provide the <command>xinetd</command>
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>via xinetd</tertiary>
+          </indexterm>
+          <indexterm>
+            <primary>xinetd</primary>
+          </indexterm>Some operating systems provide the  
<command>xinetd</command>
            daemon as an alternative to <command>inetd</command>.
            Fortunately, you can configure <command>svnserve</command> for
            use with <command>xinetd</command>, too.  To do so, you'll need  
to
@@ -643,7 +688,12 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.tunnel">
          <title>svnserve over a tunnel</title>

-        <para>Another way to invoke <command>svnserve</command> is in
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>tunnel mode</tertiary>
+          </indexterm>Another way to invoke <command>svnserve</command> is  
in
            tunnel mode, using the <option>-t</option> option.  This
            mode assumes that a remote-service program such as
            <command>rsh</command> or <command>ssh</command> has
@@ -674,7 +724,12 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.winservice">
          <title>svnserve as a Windows service</title>

-        <para>If your Windows system is a descendant of Windows NT
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>as Windows service</tertiary>
+          </indexterm>If your Windows system is a descendant of Windows NT
            (Windows 2000 or newer), you can
            run <command>svnserve</command> as a standard Windows
            service.  This is typically a much nicer experience than
@@ -772,7 +827,15 @@
        <sect3 id="svn.serverconfig.svnserve.invoking.launchd">
          <title>svnserve as a launchd job</title>

-        <para>Mac OS X (10.4 and higher) uses <command>launchd</command>
+        <para>
+          <indexterm>
+            <primary>svnserve</primary>
+            <secondary>running</secondary>
+            <tertiary>via launchd</tertiary>
+          </indexterm>
+          <indexterm>
+            <primary>launchd</primary>
+          </indexterm>Mac OS X (10.4 and higher) uses  
<command>launchd</command>
            to manage processes (including daemons) both system-wide and
            per-user.  A <command>launchd</command> job is specified by
            parameters in an XML property list file, and
@@ -907,7 +970,15 @@
      <sect2 id="svn.serverconfig.svnserve.auth">
        <title>Built-in Authentication and Authorization</title>

-      <para>When a client connects to an <command>svnserve</command>
+      <para>
+        <indexterm>
+          <primary>svnserve</primary>
+          <secondary>authentication</secondary>
+        </indexterm>
+        <indexterm>
+          <primary>svnserve</primary>
+          <secondary>authorization</secondary>
+        </indexterm>When a client connects to an  
<command>svnserve</command>
          process, the following things happen:</para>

        <itemizedlist>
@@ -3221,7 +3292,22 @@
        <sect3 id="svn.serverconfig.httpd.extra.writethruproxy">
          <title>Write-through proxying</title>

-        <para>One of the nice advantages of using Apache as a
+        <para>
+          <indexterm>
+            <primary>WebDAV</primary>
+            <secondary>proxies</secondary>
+            <see>httpd, write-through proxies</see>
+          </indexterm>
+          <indexterm>
+            <primary>httpd</primary>
+            <secondary>write-through proxies</secondary>
+            <tertiary>master</tertiary>
+          </indexterm>
+          <indexterm>
+            <primary>httpd</primary>
+            <secondary>write-through proxies</secondary>
+            <tertiary>slave</tertiary>
+          </indexterm>One of the nice advantages of using Apache as a
            Subversion server is that it can be set up for simple
            replication.  For example, suppose that your team is
            distributed across four offices around the globe.  The
=======================================
--- /trunk/en/book/ch07-customizing-svn.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ch07-customizing-svn.xml	Fri Feb  8 10:32:43 2013
@@ -33,12 +33,15 @@
        operation they perform, Subversion uses configuration files,
        segregated into a Subversion configuration area.</para>

-    <para>The Subversion <firstterm>configuration area</firstterm> is
-      a two-tiered hierarchy of option names and their values.
-      Usually, this boils down to a special directory that contains
-      <firstterm>configuration files</firstterm> (the first tier),
-      which are just text files in standard INI format where
-      <quote>sections</quote> provide the second tier.  You can
+    <para>
+      <indexterm>
+        <primary>runtime configuration</primary>
+      </indexterm>The Subversion <firstterm>runtime configuration
+      area</firstterm> is a two-tiered hierarchy of option names and
+      their values.  Usually, this boils down to a special directory
+      that contains configuration files (the first tier), which are
+      just text files in standard INI format
+      where <quote>sections</quote> provide the second tier.  You can
        easily edit these files using your favorite text editor (such as
        Emacs or vi), and they contain directives read by the client to
        determine which of several optional behaviors the user
@@ -48,7 +51,11 @@
      <sect2 id="svn.advanced.confarea.layout">
        <title>Configuration Area Layout</title>

-      <para>The first time the <command>svn</command> command-line
+      <para>
+        <indexterm>
+          <primary>runtime configuration</primary>
+          <secondary>per-user</secondary>
+        </indexterm>The first time the <command>svn</command> command-line
          client is executed, it creates a per-user configuration area.
          On Unix-like systems, this area appears as a directory
          named <filename>.subversion</filename> in the user's home
@@ -65,7 +72,11 @@
          We will refer to the per-user configuration area using its
          Unix name, <filename>.subversion</filename>.</para>

-      <para>In addition to the per-user configuration area, Subversion
+      <para>
+        <indexterm>
+          <primary>runtime configuration</primary>
+          <secondary>system-wide</secondary>
+        </indexterm>In addition to the per-user configuration area,  
Subversion
          also recognizes the existence of a system-wide configuration
          area.  This gives system administrators the ability to
          establish defaults for all users on a given machine.  Note
@@ -100,7 +111,11 @@
          configuration directory with the default contents will be
          created.</para>

-      <para>Subversion also allows you to override individual
+      <para>
+        <indexterm>
+          <primary>runtime configuration</primary>
+          <secondary>command-line override</secondary>
+        </indexterm>Subversion also allows you to override individual
          configuration option values at the command line via
          the <option>--config-option</option> option, which is
          especially useful if you need to make a (very) temporary
@@ -121,12 +136,16 @@
      <sect2 id="svn.advanced.confarea.windows-registry">
        <title>Configuration and the Windows Registry</title>

-      <para>In addition to the usual INI-based configuration area,
-        Subversion clients running on Windows platforms may also use
-        the Windows Registry to hold the configuration data.  The
+      <para>
+        <indexterm>
+          <primary>runtime configuration</primary>
+          <secondary>Windows Registry</secondary>
+        </indexterm>In addition to the usual INI-based configuration
+        area, Subversion clients running on Windows platforms may also
+        use the Windows Registry to hold the configuration data.  The
          option names and their values are the same as in the INI
-        files.  The <quote>file/section</quote> hierarchy is
-        preserved as well, though addressed in a slightly different
+        files.  The <quote>file/section</quote> hierarchy is preserved
+        as well, though addressed in a slightly different
          fashion—in this schema, files and sections are just
          levels in the Registry key tree.</para>

@@ -259,7 +278,11 @@
      <sect2 id="svn.advanced.confarea.opts">
        <title>Runtime Configuration Options</title>

-      <para>In this section, we will discuss the specific
+      <para>
+        <indexterm>
+          <primary>runtime configuration</primary>
+          <secondary>options</secondary>
+        </indexterm>In this section, we will discuss the specific
          runtime configuration options that Subversion currently
          supports.</para>

@@ -964,7 +987,10 @@
    <sect1 id="svn.advanced.l10n">
      <title>Localization</title>

-    <para><firstterm>Localization</firstterm> is the act of making
+    <para>
+      <indexterm>
+        <primary>localization</primary>
+      </indexterm><firstterm>Localization</firstterm> is the act of making
        programs behave in a region-specific way.  When a program
        formats numbers or dates in a way specific to your part of the
        world or prints messages (or accepts input) in your native
@@ -1074,7 +1100,13 @@
          can see which languages the Subversion client is able to
          speak.</para>

-      <para>The second way in which the locale is honored involves how
+      <para>
+        <indexterm>
+          <primary>internationalization</primary>
+        </indexterm>
+        <indexterm>
+          <primary>UTF-8</primary>
+        </indexterm>The second way in which the locale is honored involves  
how
          <command>svn</command> interprets your input.  The repository
          stores all paths, filenames, and log messages in Unicode,
          encoded as UTF-8.  In that sense, the repository is
=======================================
--- /trunk/en/book/ch08-embedding-svn.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ch08-embedding-svn.xml	Fri Feb  8 10:32:43 2013
@@ -3,7 +3,14 @@
  <chapter id="svn.developer">
    <title>Embedding Subversion</title>

-  <para>Subversion has a modular design: it's implemented as a
+  <para>
+    <indexterm>
+      <primary>API</primary>
+    </indexterm>
+    <indexterm>
+      <primary>application programming interface</primary>
+      <see>API</see>
+    </indexterm>Subversion has a modular design: it's implemented as a
      collection of libraries written in C.  Each library has a
      well-defined purpose and application programming interface (API),
      and that interface is available not only for Subversion itself to
@@ -31,9 +38,13 @@
    <sect1 id="svn.developer.layerlib">
      <title>Layered Library Design</title>

-    <para>Each of Subversion's core libraries can be said to exist in
-      one of three main layers—the Repository layer, the
-      Repository Access (RA) layer, or the Client layer (see
+    <para>
+      <indexterm>
+        <primary>API</primary>
+        <secondary>layers</secondary>
+      </indexterm>Each of Subversion's core libraries can be said to
+      exist in one of three main layers—the Repository layer,
+      the Repository Access (RA) layer, or the Client layer (see
        <xref linkend="svn.intro.architecture.dia-1" /> in the Preface).
        We will examine these layers shortly, but first, let's briefly
        summarize Subversion's various libraries.  For the sake of
@@ -165,7 +176,12 @@
      <sect2 id="svn.developer.layerlib.repos">
        <title>Repository Layer</title>

-      <para>When referring to Subversion's Repository layer, we're
+      <para>
+        <indexterm>
+          <primary>API</primary>
+          <secondary>layers</secondary>
+          <tertiary>Repository Layer</tertiary>
+        </indexterm>When referring to Subversion's Repository layer, we're
          generally talking about two basic concepts—the versioned
          filesystem implementation (accessed via
          <filename>libsvn_fs</filename>, and supported by its
@@ -179,7 +195,11 @@
          the perspective of the Subversion user, the stuff at the
          <quote>other end of the line.</quote></para>

-      <para>The Subversion filesystem is not a kernel-level filesystem
+      <para>
+        <indexterm>
+          <primary>repositories</primary>
+          <secondary>filesystem</secondary>
+        </indexterm>The Subversion filesystem is not a kernel-level  
filesystem
          that one would install in an operating system (such as the
          Linux ext2 or NTFS), but instead is a virtual filesystem.
          Rather than storing <quote>files</quote> and
@@ -200,7 +220,11 @@
          Subversion filesystem plug-in that used Google's ultra-scalable
          Bigtable database for its storage.</para>

-      <para>The filesystem API exported by
+      <para>
+        <indexterm>
+          <primary>repositories</primary>
+          <secondary>filesystem tree</secondary>
+        </indexterm>The filesystem API exported by
          <filename>libsvn_fs</filename> contains the kinds of
          functionality you would expect from any other filesystem
          API—you can create and remove files and directories,
@@ -399,7 +423,12 @@
      <sect2 id="svn.developer.layerlib.ra">
        <title>Repository Access Layer</title>

-      <para>If the Subversion Repository layer is at <quote>the other
+      <para>
+        <indexterm>
+          <primary>API</primary>
+          <secondary>layers</secondary>
+          <tertiary>Repository Access (RA) Layer</tertiary>
+        </indexterm>If the Subversion Repository layer is at <quote>the  
other
          end of the line,</quote> the Repository Access (RA) layer is
          the line itself.  Charged with marshaling data between the
          client libraries and the repository, this layer includes the
@@ -413,7 +442,10 @@
          <filename>libsvn_ra_svn</filename>'s server,
          <command>svnserve</command>).</para>

-      <para>Since Subversion uses URLs to identify its repository
+      <para>
+        <indexterm>
+          <primary>repository URL</primary>
+        </indexterm>Since Subversion uses URLs to identify its repository
          resources, the protocol portion of the URL scheme (usually
          <literal>file://</literal>, <literal>http://</literal>,
          <literal>https://</literal>, <literal>svn://</literal>, or
@@ -480,7 +512,12 @@
      <sect2 id="svn.developer.layerlib.client">
        <title>Client Layer</title>

-      <para>On the client side, the Subversion working copy is where
+      <para>
+        <indexterm>
+          <primary>API</primary>
+          <secondary>layers</secondary>
+          <tertiary>Client Layer</tertiary>
+        </indexterm>On the client side, the Subversion working copy is  
where
          all the action takes place.  The bulk of functionality
          implemented by the client-side libraries exists for the sole
          purpose of managing working copies—directories full of
@@ -489,7 +526,10 @@
          locations—and propagating changes to and from the
          Repository Access layer.</para>

-      <para>Subversion's working copy library,
+      <para>
+        <indexterm>
+          <primary>administrative directory</primary>
+        </indexterm>Subversion's working copy library,
          <filename>libsvn_wc</filename>, is directly responsible for
          managing the data in the working copies.  To accomplish this,
          the library stores administrative information about the
@@ -675,7 +715,11 @@
        <sidebar>
          <title>Programming with Memory Pools</title>

-        <para>Almost every developer who has used the C programming
+        <para>
+          <indexterm>
+            <primary>API</primary>
+            <secondary>memory pools</secondary>
+          </indexterm>Almost every developer who has used the C programming
            language has at some point sighed at the daunting task of
            managing memory usage.  Allocating enough memory to use,
            keeping track of those allocations, freeing the memory when
@@ -718,7 +762,11 @@
      <sect2 id="svn.developer.usingapi.funcsbatons">
        <title>Functions and Batons</title>

-      <para>To facilitate <quote>streamy</quote> (asynchronous) behavior
+      <para>
+        <indexterm>
+          <primary>API</primary>
+          <secondary>batons</secondary>
+        </indexterm>To facilitate <quote>streamy</quote> (asynchronous)  
behavior
          and provide consumers of the Subversion C API with hooks for
          handling information in customizable ways, many functions in
          the API accept pairs of parameters: a pointer to a callback
=======================================
--- /trunk/en/book/ref-reposhooks.xml	Thu Feb  7 12:43:50 2013
+++ /trunk/en/book/ref-reposhooks.xml	Fri Feb  8 10:32:43 2013
@@ -13,9 +13,8 @@
      <refentry id="svn.ref.reposhooks.start-commit">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>start-commit</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>start-commit</secondary>
        </indexterm>

        <refnamediv>
@@ -110,9 +109,8 @@
      <refentry id="svn.ref.reposhooks.pre-commit">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>pre-commit</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>pre-commit</secondary>
        </indexterm>

        <refnamediv>
@@ -183,9 +181,8 @@
      <refentry id="svn.ref.reposhooks.post-commit">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>post-commit</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>post-commit</secondary>
        </indexterm>

        <refnamediv>
@@ -245,9 +242,8 @@
      <refentry id="svn.ref.reposhooks.pre-revprop-change">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>pre-revprop-change</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>pre-revprop-change</secondary>
        </indexterm>

        <refnamediv>
@@ -326,9 +322,8 @@
      <refentry id="svn.ref.reposhooks.post-revprop-change">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>post-revprop-change</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>post-revprop-change</secondary>
        </indexterm>

        <refnamediv>
@@ -410,9 +405,8 @@
      <refentry id="svn.ref.reposhooks.pre-lock">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>pre-lock</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>pre-lock</secondary>
        </indexterm>

        <refnamediv>
@@ -502,9 +496,8 @@
      <refentry id="svn.ref.reposhooks.post-lock">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>post-lock</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>post-lock</secondary>
        </indexterm>

        <refnamediv>
@@ -566,9 +559,8 @@
      <refentry id="svn.ref.reposhooks.pre-unlock">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>pre-unlock</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>pre-unlock</secondary>
        </indexterm>

        <refnamediv>
@@ -643,9 +635,8 @@
      <refentry id="svn.ref.reposhooks.post-unlock">

        <indexterm>
-        <primary>repository</primary>
-        <secondary>hooks</secondary>
-        <tertiary>post-unlock</tertiary>
+        <primary>hook scripts</primary>
+        <secondary>post-unlock</secondary>
        </indexterm>

        <refnamediv>




More information about the svnbook-dev mailing list