[svnbook commit] r1465 - in trunk/src/nb: . book

sunny256 svnbook-dev at red-bean.com
Fri Jun 17 15:50:27 CDT 2005


Author: sunny256
Date: Fri Jun 17 15:50:26 2005
New Revision: 1465

Added:
   trunk/src/nb/book/appb.xml   (props changed)
      - copied unchanged from r1464, trunk/src/en/book/appb.xml
   trunk/src/nb/book/appc.xml
      - copied unchanged from r1464, trunk/src/en/book/appc.xml
Removed:
   trunk/src/nb/book/appd.xml
Modified:
   trunk/src/nb/LAST_UPDATED
   trunk/src/nb/Makefile
   trunk/src/nb/book/book.xml
   trunk/src/nb/book/ch00.xml
   trunk/src/nb/book/ch02.xml
   trunk/src/nb/book/ch05.xml
   trunk/src/nb/book/ch06.xml
   trunk/src/nb/book/ch07.xml
   trunk/src/nb/book/ch09.xml
Log:
Sync the Norwegian svnbook against the English version, r1430:1464.

* src/nb/LAST_UPDATED
  Updated to 1464 by make sync.

* src/nb/book/appb.xml
  Deleted in r1449 and replaced by appc.xml in r1450.

* src/nb/book/appc.xml
  Merged r1440. Moved to appb.xml in r1450 and replaced by appd.xml in 
  r1451. Merged r1452, r1453.

* src/nb/book/appd.xml
  Removed after all the renames.

* src/nb/book/book.xml
  Merged r1449, r1450, r1451.

* src/nb/book/ch00.xml
  Merged r1460.

* src/nb/book/ch02.xml
  Merged r1433, r1442.

* src/nb/book/ch05.xml
  Merged r1433, r1443, r1446.

* src/nb/book/ch06.xml
  Merged r1433.

* src/nb/book/ch07.xml
  Merged r1442, r1444, r1448, r1456, r1457, r1458.

* src/nb/book/ch09.xml
  Merged r1433, r1443, r1444, r1449.

* src/nb/Makefile
  (BOOKFILES, BDFILES): Removed appd.xml .


Modified: trunk/src/nb/LAST_UPDATED
==============================================================================
--- trunk/src/nb/LAST_UPDATED	(original)
+++ trunk/src/nb/LAST_UPDATED	Fri Jun 17 15:50:26 2005
@@ -1 +1 @@
-1430
+1464

Modified: trunk/src/nb/Makefile
==============================================================================
--- trunk/src/nb/Makefile	(original)
+++ trunk/src/nb/Makefile	Fri Jun 17 15:50:26 2005
@@ -9,14 +9,14 @@
 COLLAB=http://svn.red-bean.com/svnbook
 
 BUILDTMP_DIR = build.tmp
-BOOKFILES = appa.xml appb.xml appc.xml appd.xml book.xml ch00.xml \
-            ch01.xml ch02.xml ch03.xml ch04.xml ch05.xml ch06.xml \
-            ch07.xml ch08.xml ch09.xml copyright.xml foreword.xml
+BOOKFILES = appa.xml appb.xml appc.xml book.xml ch00.xml ch01.xml \
+			ch02.xml ch03.xml ch04.xml ch05.xml ch06.xml ch07.xml \
+			ch08.xml ch09.xml copyright.xml foreword.xml
 
 BDTMP = bd.tmp
 BDFILES = book.xml foreword.xml ch00.xml ch01.xml ch02.xml ch03.xml \
           ch04.xml appa.xml ch05.xml ch06.xml ch07.xml ch08.xml \
-          ch09.xml appb.xml appc.xml appd.xml copyright.xml
+          ch09.xml appb.xml appc.xml copyright.xml
 
 build: dircheck htmlbook copytobuild
 

Modified: trunk/src/nb/book/book.xml
==============================================================================
--- trunk/src/nb/book/book.xml	(original)
+++ trunk/src/nb/book/book.xml	Fri Jun 17 15:50:26 2005
@@ -18,7 +18,6 @@
 <!ENTITY appa     SYSTEM "appa.xml">
 <!ENTITY appb     SYSTEM "appb.xml">
 <!ENTITY appc     SYSTEM "appc.xml">
-<!ENTITY appd     SYSTEM "appd.xml">
 <!ENTITY license  SYSTEM "copyright.xml">
 ]>
 @ENGLISH }}} -->
@@ -40,7 +39,6 @@
 <!ENTITY appa     SYSTEM "appa.xml">
 <!ENTITY appb     SYSTEM "appb.xml">
 <!ENTITY appc     SYSTEM "appc.xml">
-<!ENTITY appd     SYSTEM "appd.xml">
 <!ENTITY license  SYSTEM "copyright.xml">
 ]>
 
@@ -149,7 +147,6 @@
   &appa;
   &appb;
   &appc;
-  &appd;
   &license;
 
 </book>

Modified: trunk/src/nb/book/ch00.xml
==============================================================================
--- trunk/src/nb/book/ch00.xml	(original)
+++ trunk/src/nb/book/ch00.xml	Fri Jun 17 15:50:26 2005
@@ -720,304 +720,6 @@
 
   </sect1>
 
-  <!-- ================================================================= -->
-  <!-- ======================== SECTION 4b ============================= -->
-  <!-- ================================================================= -->
-  <sect1 id="svn.preface.new-1-1">
-    <!-- @ENGLISH {{{
-    <title>New in Subversion 1.1</title>
-    @ENGLISH }}} -->
-    <title>Nytt i Subversion 1.1</title>
-
-    <!-- @ENGLISH {{{
-    <para>This edition of the book has been updated to cover new
-      features and behavioral changes in Subversion 1.1.  Here's a
-      brief list of pointers to major 1.1 changes.</para>
-    @ENGLISH }}} -->
-    <para>Denne utgaven av boken er blitt oppdatert for å dekke nye 
-      funksjoner og forandringer i oppførselen for Subversion 1.1.
-      Her er en rask oversikt over pekere til store forandringer i 
-      1.1.</para>
-
-    <variablelist>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Non-database repositories</term>
-        <listitem>
-          <para>It's now possible to create repositories that don't
-            use a BerkeleyDB database.  Instead, these new
-            repositories store data in the ordinary filesystem using a
-            custom file format.  These repositories aren't susceptible
-            to <quote>wedging</quote>, but also aren't as well-tested
-            as Berkeley DB repositories.  See <xref
-            linkend="svn.reposadmin.basics.backends"/>.</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Depot uten database</term>
-        <listitem>
-          <para>Det er nå mulig å opprette depot som ikke bruker en 
-            Berkeley DB database.
-            Istedenfor lagrer disse nye depotene data i det ordinære 
-            filsystemet ved å bruke et tilpasset format.
-            Disse depotene er ikke sårbare for <!-- ¤ wedge = kile 
-            (subst), kile fast (verb). Kanskje det går an å bruke en 
-            variasjon av det. «Fastkilt»? --><quote>wedging</quote>, men 
-            er heller ikke så gjennomtestet som Berkeley DB-depot.
-            Se <xref linkend="svn.reposadmin.basics.backends"/>.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Symbolic link versioning</term>
-        <listitem>
-          <para>Unix users can now create symbolic links and place
-            them under version control with the <command>svn
-            add</command> command.  See <xref
-            linkend="svn.ref.svn.c.add"/> and <xref
-            linkend="svn.advanced.props.special.special"/>.</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Versjonering av symbolske lenker</term>
-        <listitem>
-          <para>Unixbrukere kan nå opprette symbolske lenker og plassere 
-            dem under versjonskontroll med <command>svn 
-            add</command>-kommandoen.
-            Se <xref linkend="svn.ref.svn.c.add"/> og <xref 
-            linkend="svn.advanced.props.special.special"/>.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Client follows copies and renames</term>
-        <listitem>
-          <para>Branches (copies) of files and directories maintain
-            historical connections to their source, but in Subversion
-            1.0 only <command>svn log</command> ever followed that
-            copy/rename history, not other commands like <command>svn
-            diff</command>, <command>svn merge</command>, <command>svn
-            list</command>, or <command>svn cat</command>.  In
-            Subversion 1.1, all client subcommands now transparently
-            trace backwards through copies and renames when examining
-            older versions of files and directories.</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Klienten følger kopieringer og navneskifter</term>
-        <listitem>
-          <para>Forgreninger (kopier) av filer og kataloger 
-            vedlikeholder historiske forbindelser til kilden deres, men 
-            i Subversion 1.0 fulgte bare <command>svn log</command> 
-            denne kopierings/navneskiftehistorien, ikke andre kommandoer 
-            som <command>svn diff</command>, <command>svn 
-            merge</command>, <command>svn list</command> eller 
-            <command>svn cat</command>.
-            I Subversion 1.1 tråler alle delkommandoene seg bakover 
-            gjennom kopieringer og navneskifter ved undersøkelser av 
-            eldre versjoner av filer og kataloger.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Client auto-escaping of URIs and IRIs</term>
-        <listitem>
-          <para>In the 1.0 command-line client, users had to escape
-            URLs manually.  The client only accepted <quote>legally
-            correct</quote> URLs, such as
-            <literal>http://host/path%20with%20space/project/espa%F1a</literal>.
-            The 1.1 command-line client now knows how to do what
-            web-browsers have been doing for long time: it
-            auto-escapes characters like spaces and accented letters,
-            as long as the user places the
-            URL in quotes to protect characters from the shell:
-            <literal>"http://host/path with
-            space/project/españa"</literal></para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Autobeskytting i klienten av URI-er og IRI-er</term>
-        <listitem>
-          <para>I kommandolinjeklienten for 1.0 måtte brukere beskytte 
-            (<quote>escape</quote>) URL-er manuelt.
-            Klienten aksepterte bare <quote>lovlige og korrekte</quote> 
-            URL-er, som 
-            <literal>http://tjener/sti%20med%20mellomrom/prosjekt/espa%F1a</literal>.
-            Kommandolinjeklienten for 1.1 vet nå hvordan den skal gjøre 
-            det som nettlesere har gjort i lang tid:
-            Den autobeskytter tegn som mellomrom og bokstaver med 
-            aksent, så lenge brukeren plasserer URL-en i hermetegn for å 
-            beskytte tegn fra skallet:
-            <literal>"http://tjener/sti med 
-            mellomrom/prosjekt/españa"</literal></para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Localized user messages</term>
-        <listitem>
-          <para>Subversion 1.1 is now using
-            <literal>gettext()</literal> to display translated error,
-            informational, and help messages to the user. There are
-            currently translations for German, Spanish, Polish,
-            Swedish, Traditional Chinese, Japanese, Brazilian
-            Portuguese and Norwegian Bokmal.  To localize your
-            Subversion client, just set your shell's LANG environment
-            variable to a supported locale value (for example,
-            <literal>de_DE</literal>).</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Lokaliserte brukermeldinger</term>
-        <listitem>
-          <para>Subversion 1.1 bruker nå <literal>gettext()</literal> 
-            for å vise oversatte feil-, informasjons- og hjelpemeldinger 
-            til brukeren.
-            Det er foreløpige oversettelser for tysk, spansk, polsk, 
-            svensk, tradisjonell kinesisk, japansk, portugisisk (Brasil) 
-            og norsk (bokmål).
-            For å få Subversion til å bruke en av oversettelsene, sett 
-            skallets LANG-variabel til en støttet verdi (for eksempel 
-            <literal>nb_NO</literal>).</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Shareable working copies</term>
-        <listitem>
-          <para>There have been historical problems with permissions
-            when multiple users share a working copy, which are
-            believed to be fixed now.</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Delbare arbeidskopier</term>
-        <listitem>
-          <para>Det har vært historiske problemer med 
-            tilgangsrettigheter når flere brukere deler en arbeidskopi, 
-            det ser ut til å være ordnet nå.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term><literal>store-passwords</literal> run-time variable</term>
-        <listitem>
-          <para>This is a new runtime variable which only disables
-            password caching, so that server certificates can still be
-            cached.  See <xref linkend="svn.advanced.confarea.opts.config"/>.</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term><literal>store-passwords</literal> kjørevariabel</term>
-        <listitem>
-          <para>Dette er en ny variabel for bruk under kjøring som bare 
-            kobler ut lagring av passord, så tjenersertifikater fortsatt 
-            kan lagres. Se <xref 
-            linkend="svn.advanced.confarea.opts.config"/>.</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>Optimizations and bug fixes</term>
-        <listitem>
-          <para>The <command>svn checkout</command>, <command>svn
-            update</command>, <command>svn status</command>, and
-            <command>svn blame</command> commands are faster.  More
-            than fifty small bugs have been fixed, all described in
-            the Subversion project's CHANGES file (at <systemitem
-            class="url">http://svn.collab.net/repos/svn/trunk/CHANGES
-            </systemitem>).</para>
-        </listitem>
-        @ENGLISH }}} -->
-        <term>Optimaliseringer og feilrettinger</term>
-        <listitem>
-          <para>Kommandoene <command>svn checkout</command>, 
-            <command>svn update</command>, <command>svn status</command> 
-            og <command>svn blame</command> er raskere.
-            Mer enn femti små feil er blitt fikset, alle beskrevet i 
-            Subversionprosjektets CHANGES-fil (på <systemitem 
-            class="url">http://svn.collab.net/repos/svn/trunk/CHANGES 
-            </systemitem>).</para>
-        </listitem>
-      </varlistentry>
-
-      <varlistentry>
-        <!-- @ENGLISH {{{
-        <term>New command switches</term>
-        @ENGLISH }}} -->
-        <term>Nye kommandobrytere</term>
-        <listitem>
-          <itemizedlist>
-            <!-- @ENGLISH {{{
-            <listitem><para><command>svn blame -ﳢ-verbose</command>: see
-            <xref linkend="svn.ref.svn.c.blame"/>.
-            </para></listitem>
-
-            <listitem><para><command>svn export -ﳢ-native-eol EOL</command>: see
-            <xref linkend="svn.ref.svn.c.export"/>.
-            </para></listitem>
-            
-            <listitem><para><command>svn add -ﳢ-force</command>: see
-            <xref linkend="svn.ref.svn.c.add"/>.
-            </para></listitem>
-
-            <listitem><para><command>svnadmin dump -ﳢ-deltas</command>: see
-            <xref linkend="svn.reposadmin.maint.migrate"/>.
-            </para></listitem>
-
-            <listitem><para><command>svnadmin create -ﳢ-fs-type TYPE</command>: see
-            <xref linkend="svn.ref.svnadmin.c.create"/>.
-            </para></listitem>
-
-            <listitem><para><command>svnadmin recover -ﳢ-wait</command>: see
-            <xref linkend="svn.ref.svnadmin.c.recover"/>.
-            </para></listitem>
-
-            <listitem><para><command>svnserve -ﳢ-tunnel-user=NAME</command>: see
-            <xref linkend="svn.ref.svnserve.sw"/>.
-            </para></listitem>
-            @ENGLISH }}} -->
-            <listitem>
-              <para><command>svn blame --verbose</command>: Se <xref 
-                linkend="svn.ref.svn.c.blame"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svn export --native-eol EOL</command>: Se 
-                <xref linkend="svn.ref.svn.c.export"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svn add --force</command>: Se <xref 
-                linkend="svn.ref.svn.c.add"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svnadmin dump --deltas</command>: Se <xref 
-                linkend="svn.reposadmin.maint.migrate"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svnadmin create --fs-type TYPE</command>: 
-                Se <xref linkend="svn.ref.svnadmin.c.create"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svnadmin recover --wait</command>: Se <xref 
-                linkend="svn.ref.svnadmin.c.recover"/>.</para>
-            </listitem>
-
-            <listitem>
-              <para><command>svnserve --tunnel-user=NAME</command>: Se 
-                <xref linkend="svn.ref.svnserve.sw"/>.</para>
-            </listitem>
-          </itemizedlist>
-        </listitem>
-      </varlistentry>
-    </variablelist>
-
-  </sect1>
 
   <!-- ================================================================= -->
   <!-- ======================== SECTION 5 ============================== -->

Modified: trunk/src/nb/book/ch02.xml
==============================================================================
--- trunk/src/nb/book/ch02.xml	(original)
+++ trunk/src/nb/book/ch02.xml	Fri Jun 17 15:50:26 2005
@@ -530,13 +530,13 @@
         <para>The copy-modify-merge model is based on the assumption
           that files are contextually mergeable: that is, that the
           majority of the files in the repository are line-based text
-          files (such as program source code.)  But for files with
+          files (such as program source code).  But for files with
           binary formats, such as artwork or sound, it's often
           impossible to merge conflicting changes.  In these
           situations, it really is necessary to users to take strict
           turns when changing the file.  Without serialized access,
-          somebody ends up wasting their time on changes that are
-          ultimately discarded.</para>
+          somebody ends up wasting time on changes that are ultimately
+          discarded.</para>
         @ENGLISH }}} -->
         <para>Modellen kopier-rediger-flett er basert på forutsetningen 
           om at filer er flettbare, det vil si at majoriteten av filene 

Modified: trunk/src/nb/book/ch05.xml
==============================================================================
--- trunk/src/nb/book/ch05.xml	(original)
+++ trunk/src/nb/book/ch05.xml	Fri Jun 17 15:50:26 2005
@@ -712,7 +712,7 @@
           Most SQL systems, for example, have a dedicated server
           process that mediates all access to tables.  If a program
           accessing the database crashes for some reason, the database
-          daemon notices the lost connection and clean up any mess
+          daemon notices the lost connection and cleans up any mess
           left behind.  And because the database daemon is the only
           process accessing the tables, applications don't need to
           worry about permission conflicts.  These things are not the
@@ -725,7 +725,7 @@
           Other things can cause a repository to <quote>wedge</quote>
           besides crashed processes, such as programs conflicting over
           ownership and permissions on the database files.  So while a
-          BerkeleyDB repository is quite fast and scalable, it's best
+          Berkeley DB repository is quite fast and scalable, it's best
           used by a single server process running as one
           user—such as Apache's <command>httpd</command> or
           <command>svnserve</command> (see <xref
@@ -741,8 +741,9 @@
           De fleste SQL-systemer har for eksempel en dedikert 
           tjenerprosess som fordeler all tilgang til tabeller.
           Hvis et program som aksesserer databasen krasjer av en eller 
-          annen grunn, oppdager daemonen som styrer databasen dette og 
-          ordner opp i eventuelt rot som blir liggende igjen.
+          annen grunn, oppdager daemonen som styrer databasen at 
+          forbindelsen er brutt og ordner opp i eventuelt rot som blir 
+          liggende igjen.
           Og fordi databasedaemonen er den eneste prosessen som 
           aksesserer tabellene, trenger ikke applikasjoner å tenke på 
           rettighetskonflikter.
@@ -837,7 +838,7 @@
           checking out the latest tree is a bit slower than fetching
           the fulltexts stored in a Berkeley DB HEAD revision.  FSFS
           also has a longer delay when finalizing a commit, which
-          could in extreme cases cause clients to time-out when
+          could in extreme cases cause clients to time out when
           waiting for a response.</para>
         @ENGLISH }}} -->
         <para>FSFS har også forskjellige karakteristikker når det 
@@ -1616,13 +1617,13 @@
               create a more complex policy specifying exactly which
               users are allowed to lock particular paths.  If the hook
               notices a pre-existing lock, then it can also decide
-              whether a user is allowed to "steal" the existing lock.
-              The repository passes three arguments to the hook: the
-              path to the repository, the path being locked, and the
-              user attempting to perform the lock.  If the program
-              returns a non-zero exit value, the lock action is
-              aborted and anything printed to stderr is marshalled
-              back to the client.</para>
+              whether a user is allowed to <quote>steal</quote> the
+              existing lock.  The repository passes three arguments to
+              the hook: the path to the repository, the path being
+              locked, and the user attempting to perform the lock.  If
+              the program returns a non-zero exit value, the lock
+              action is aborted and anything printed to stderr is
+              marshalled back to the client.</para>
             @ENGLISH }}} -->
             <para>Denne påhakningen kjøres hver gang noen prøver å låse 
               en fil.
@@ -2625,7 +2626,7 @@
           </varlistentry>
 
           <varlistentry>
-            <term><literal>lstxns</literal></term>
+            <term><literal>lslocks</literal></term>
             <listitem>
               <!-- @ENGLISH {{{
               <para>List and describe any locks that exist in the
@@ -4429,8 +4430,8 @@
 
 </screen>
       @ENGLISH }}} -->
-      <!-- ¤ --><screen>
-$ svnadmin load nyttdepot < dumpfil
+      <screen>
+$ svnadmin load newrepos < dumpfile
 <<< Started new txn, based on original revision 1
      * adding path : A ... done.
      * adding path : A/B ... done.
@@ -4459,6 +4460,48 @@
 </screen>
 
       <!-- @ENGLISH {{{
+      <para>The result of a load is new revisions added to a
+        repository—the same thing you get by making commits
+        against that repository from a regular Subversion client.  And
+        just as in a commit, you can use hook scripts to perform
+        actions before and after each of the commits made during a load
+        process.  By passing the <option>-ﳢ-use-pre-commit-hook</option> 
+        and <option>-ﳢ-use-post-commit-hook</option> options to
+        <command>svnadmin load</command>, you can instruct Subversion
+        to execute the pre-commit and post-commit hook scripts,
+        respectively, for each loaded revision.  You might use these,
+        for example, to ensure that loaded revisions pass through the
+        same validation steps that regular commits pass through.  Of
+        course, you should use these options with care—if your
+        post-commit hook sends emails to a mailing list for each new
+        commit, you might not want to spew hundreds or thousands of
+        commit emails in rapid succession at that list for each of the
+        loaded revisions!  You can read more about the use of hook 
+        scripts in <xref linkend="svn.reposadmin.create.hooks"/>.</para>
+      @ENGLISH }}} -->
+      <para>Resultatet av en lasting er at nye revisjoner blir lagt til 
+        et depot – det samme som skjer når du legger inn revisjoner i 
+        depotet fra en vanlig Subversionklient.
+        Og akkurat som i en innlegging kan du bruke påhakningsskript for  
+        å utføre oppgaver før og etter hver av innleggingene som blir 
+        gjort under en lasteprosess.
+        Ved å angi valgene <option>--use-pre-commit-hook</option> og 
+        <option>--use-post-commit-hook</option> sammen med 
+        <command>svnadmin load</command>, kan du instruere Subversion 
+        til å utføre henholdsvis pre-commit- og post-commit-skriptene 
+        for hver lastede revisjon.
+        Du kan for eksempel bruke disse til å forsikre deg om at de 
+        lastede revisjonene går gjennom de samme valideringsstegene som 
+        vanlige innlegginger går gjennom.
+        Selvfølgelig bør du bruke disse valgene med forsiktighet – hvis 
+        post-commit-påhakningen sender epost til en postliste for hver 
+        ny revisjon, vil du nok ikke sende ut hundre- eller tusenvis av 
+        innleggingsmeldinger i rask rekkefølge til denne listen for hver 
+        eneste lastede revisjon!
+        Du kan lese mer om bruken av påhakningsskript i <xref 
+        linkend="svn.reposadmin.create.hooks"/>.</para>
+
+      <!-- @ENGLISH {{{
       <para>Note that because <command>svnadmin</command> uses
         standard input and output streams for the repository dump and
         load process, people who are feeling especially saucy can try
@@ -4782,7 +4825,7 @@
         it should be relatively easy to describe generic sets of
         changes—each of which should be treated as a new
         revision—using this file format.  In fact, the
-        <command>cvs2svn.py</command> utility (see <xref
+        <command>cvs2svn</command> utility (see <xref
         linkend="svn.forcvs.convert"/>) uses the dump format to represent the
         contents of a CVS repository so that those contents can be
         moved in a Subversion repository.</para>
@@ -4796,10 +4839,10 @@
         eposter.</para></footnote> skulle det være relativt enkelt å 
         beskrive generelle sett med forandringer – ved å bruke dette 
         filformatet.
-        Faktisk bruker programmet <command>cvs2svn.py</command> (se 
-        <xref linkend="svn.forcvs.convert"/>) dumpformatet for å 
-        representere innholdet i et CVS-depot så dette innholdet kan bli 
-        flyttet inn i et Subversiondepot.</para>
+        Faktisk bruker programmet <command>cvs2svn</command> (se <xref 
+        linkend="svn.forcvs.convert"/>) dumpformatet for å representere 
+        innholdet i et CVS-depot så dette innholdet kan bli flyttet inn 
+        i et Subversiondepot.</para>
 
     </sect2>
 

Modified: trunk/src/nb/book/ch06.xml
==============================================================================
--- trunk/src/nb/book/ch06.xml	(original)
+++ trunk/src/nb/book/ch06.xml	Fri Jun 17 15:50:26 2005
@@ -494,7 +494,7 @@
 $ svn commit -F new_msg.txt
 Authentication realm: <svn://host.example.com:3690> example realm
 Username:  joe
-[...]
+…
 </screen>
 @ENGLISH }}} -->
         <!-- ¤ --><screen>

Modified: trunk/src/nb/book/ch07.xml
==============================================================================
--- trunk/src/nb/book/ch07.xml	(original)
+++ trunk/src/nb/book/ch07.xml	Fri Jun 17 15:50:26 2005
@@ -1693,25 +1693,10 @@
           file becomes read-write.  When the lock is released, the
           file becomes read-only again.</para>
 
-        <para>Users and administrators are encouraged to attach this
-          property to any file which cannot be contextually merged,
-          such as binary or proprietary-formatted files.  The main
-          idea is to prevent wasted time;  if the file is normally
-          read-only, then users will be reminded to lock the file
-          before editing, thus discovering any pre-existing
-          locks.</para>
-
-        <para>Note that this property is a communication system which
-          works independent of the locking system.  In other words,
-          any file can be locked, whether or not this property is
-          present.  And conversely, the presence of this property
-          doesn't make the repository require a lock.  It's possible
-          for a misbehaving application to "hijack" the read-only
-          file, edit it anyway, then allow the user to commit without
-          a lock.</para>
-
-        <para>For more on locking, see <xref
-        linkend="svn.advanced.locking"/>.</para>
+        <para>To learn more about how, when, and why this property
+          should be used, see
+          <xref
+          linkend="svn.advanced.locking.lock-communication"/>.</para>
       </sect3>
 
     </sect2>
@@ -1777,6 +1762,559 @@
   <sect1 id="svn.advanced.locking">
     <title>Locking</title>
 
+    <para>Subversion's <quote>copy-modify-merge</quote> model is
+      optimal when users are collaborating on projects that consist of
+      line-based text files, such as program source code.  However, as
+      discussed in <xref
+      linkend="svn.basic.vsn-models.copy-merge.sb-1"/>, sometimes one
+      has to use the <quote>lock-modify-unlock</quote> model instead
+      of Subversion's standard concurrent model.  When a file consists
+      of binary data, it's often difficult or impossible to merge two
+      sets of changes made in parallel by different users.  For this
+      reason, Subversion 1.2 and later offers a feature known as
+      <firstterm>locking</firstterm>, often known as <quote>reserved
+      checkouts</quote> in other version control systems.</para>
+
+    <para>Subversion's locking feature has two main goals:</para>
+
+    <itemizedlist>
+      <listitem><para><emphasis>Serializing access to a
+          resource</emphasis>.  Allow a user to grab an exclusive
+          right to change to a file in the repository.  If Harry
+          reserves the right to change <filename>foo.jpg</filename>,
+          then Sally should not be able to commit a change to it.</para>
+      </listitem>
+      <listitem><para><emphasis>Aiding communication</emphasis>.
+          Prevent users from wasting time on unmergeable changes.  If
+          Harry has reserved the right to change
+          <filename>foo.jpg</filename>, then it should be easy for
+          Sally to notice this fact and avoid working on the
+          file.</para>
+      </listitem>
+    </itemizedlist>
+
+    <para>Subversion's locking feature is currently limited to files
+      only—it's not yet possible to reserve access to a whole
+      directory tree.</para>
+
+    <sect2 id="svn.advanced.locking.creation">
+      <title>Creating locks</title>
+      
+      <para>In the Subversion repository, a
+        <firstterm>lock</firstterm> is a piece of metadata which
+        grants exclusive access to one user to change a file.  This
+        user is said to be the <firstterm>lock owner</firstterm>.
+        Each lock also has a unique identifier, typically a long
+        string of characters, known as the <firstterm>lock
+        token</firstterm>.  The repository manages locks in a separate
+        table, and enforces locks during a commit operation.  If any
+        commit transaction attempts to modify or delete the file (or
+        delete a parent of the file), the repository will demand two
+        pieces of information:</para>
+      
+      <orderedlist>
+        <listitem><para><emphasis role="bold">User
+          authentication</emphasis>.  The client performing the commit
+          must be authenticated as the lock owner.</para>
+        </listitem>
+        <listitem><para><emphasis role="bold">Software
+          authorization</emphasis>.  The user's working copy must send
+          the lock token with the commit, proving that it knows
+          exactly which lock it's using.</para>
+        </listitem>
+      </orderedlist>
+      
+      <para>An example is in order, to demonstrate.  Let's say that
+        Harry has decided to change a JPEG image.  To prevent other
+        people from committing changes to the file, he locks the file
+        in the repository using the <command>svn lock</command>
+        command:</para>
+
+      <screen>
+$ svn lock banana.jpg --message "Editing file for tomorrow's release."
+'banana.jpg' locked by user 'harry'.
+
+$ svn status
+     K banana.jpg
+
+$ svn info banana.jpg
+Path: banana.jpg
+Name: banana.jpg
+URL: http://svn.example.com/repos/project/banana.jpg
+Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
+Revision: 2198
+Node Kind: file
+Schedule: normal
+Last Changed Author: frank
+Last Changed Rev: 1950
+Last Changed Date: 2005-03-15 12:43:04 -0600 (Tue, 15 Mar 2005)
+Text Last Updated: 2005-06-08 19:23:07 -0500 (Wed, 08 Jun 2005)
+Properties Last Updated: 2005-06-08 19:23:07 -0500 (Wed, 08 Jun 2005)
+Checksum: 3b110d3b10638f5d1f4fe0f436a5a2a5
+Lock Token: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
+Lock Owner: harry
+Lock Created: 2005-06-14 17:20:31 -0500 (Tue, 14 Jun 2005)
+Lock Comment (1 line):
+Editing file for tomorrow's release.
+
+</screen>
+
+      <para>There are a number of new things demonstrated in the
+        previous example.  First, notice that Harry passed the
+        <option>--message</option> option to <command>svn
+        lock</command>.  Similar to <command>svn commit</command>,
+        the <command>svn lock</command> command can take comments
+        (either via
+        <option>--message (-m)</option> or <option>--file
+        (-F)</option>) to describe the reason for locking the file.
+        Unlike <command>svn commit</command>, however, <command>svn
+        lock</command> will not demand a message by launching your
+        preferred text editor.  Lock comments are optional, but still
+        recommended to aid communication.</para>
+
+      <para>Second, the lock attempt succeeded.  This means that the
+        file wasn't already locked, and that Harry had the latest
+        version of the file.  If Harry's working copy of the file had
+        been out-of-date, the repository would have rejected the
+        request, forcing harry to <command>svn update</command> and
+        reattempt the locking command.</para>
+
+      <para>Also notice that after creating the lock in the
+        repository, the working copy has cached information about the
+        lock—most importantly, the lock token.  The presence of
+        the lock token is critical.  It gives the working copy
+        authorization to make use of the lock later on.  The
+        <command>svn status</command> command shows a
+        <literal>K</literal> next to the file (short for locKed),
+        indicating that the lock token is present.</para>
+
+      <sidebar>
+        <title>Regarding lock tokens</title>
+
+        <para>A lock token isn't an authentication token, so much as
+          an <emphasis>authorization</emphasis> token.  The token
+          isn't a protected secret.  In fact, a lock's unique token is
+          discoverable by anyone who runs <command>svn info
+          URL</command>.</para>
+
+        <para>A lock token is special only when it lives inside a
+          working copy.  It's proof that the lock was created in that
+          particular working copy, and not somewhere else by some
+          other client.  Merely authenticating as the lock owner isn't
+          enough to prevent accidents.</para>
+
+        <para>For example: suppose you lock a file using a computer at
+         your office, perhaps as part of a changeset in progress.  It
+         should not be possible for a working copy (or alternate
+         Subversion client) on your home computer to accidentally
+         commit a change to that same file, just because you've
+         authenticated as the lock's owner.  In other words, the lock
+         token prevents one piece of Subversion-related software from
+         undermining the work of another.  (In our example, if you
+         really need to change the file from an alternate working
+         copy, you would need to break the lock and re-lock the
+         file.)</para>
+      </sidebar>
+
+      <para>Now that Harry has locked <filename>banana.jpg</filename>,
+        Sally is unable to change or delete that file:</para>
+
+      <screen>
+$ whoami
+sally
+
+$ svn delete banana.jpg
+D         banana.jpg
+
+$ svn commit -m "Delete useless file."
+Deleting       banana.jpg
+svn: Commit failed (details follow):
+svn: DELETE of
+'/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/banana.jpg':
+423 Locked (http://svn.example.com)
+
+</screen>
+
+      <para>But Harry, after touching up the banana's shade of yellow,
+        is able to commit his changes to the file.  That's because he
+        authenticates as the lock owner, and also because his working
+        copy holds the correct lock token:</para>
+
+      <screen>
+$ whoami
+harry
+
+$ svn status
+M    K banana.jpg
+
+$ svn commit -m "Make banana more yellow"
+Sending        banana.jpg
+Transmitting file data .
+Committed revision 2201.
+
+$ svn status
+$
+</screen>
+
+      <para>Notice that after the commit is finished, <command>svn
+          status</command> shows that the lock token is no longer
+          present in working copy.  This is the standard behavior
+          of <command>svn commit</command>: it walks the working copy
+          (or list of targets, if you provide such a list), and sends
+          all lock tokens it encounters to the server as part of the
+          commit transaction.  After the commit completes
+          successfully, all of the repository locks that were
+          mentioned are released—<emphasis>even on files that
+          weren't committed.</emphasis> The rationale here is to
+          discourage users from being sloppy about locking, or from
+          holding locks for too long.  For example, suppose Harry were
+          to haphazardly lock thirty files in a directory named
+          <filename>images</filename>, because he's unsure of which
+          files he needs to change.  He ends up making changes to only
+          four files.  When he runs <command>svn commit
+          images</command>, the process would still release all thirty
+          locks.</para>
+
+      <para>This behavior of automatically releasing locks can be
+          overridden with the <option>--no-unlock</option> option
+          to <command>svn commit</command>.  This is best used for
+          those times when you want to commit changes, but still plan
+          to make more changes and thus need to retain existing locks.
+          This behavior is also semi-permanently tweakable, by setting
+          <literal>no-unlock = yes</literal> in your run-time
+          <filename>config</filename> file (see <xref
+          linkend="svn.advanced.confarea"/>.)</para>
+
+      <para>Of course, locking a file doesn't oblige one to commit a
+        change to it.  The lock can be released at any time with a
+        simple
+        <command>svn unlock</command> command:</para>
+
+      <screen>
+$ svn unlock banana.c
+'banana.c' unlocked.
+</screen>
+
+    </sect2>
+
+    <sect2 id="svn.advanced.locking.discovery">
+      <title>Discovering locks</title>
+
+      <para>When a commit fails due to someone else's locks, it's
+        fairly easy to learn about them.  The easiest of
+        these is <command>svn status --show-updates</command>:</para>
+
+      <screen>
+$ whoami
+sally
+
+$ svn status --show-updates
+M              23   bar.c
+M    O         32   raisin.jpg
+       *       72   foo.h
+Status against revision:     105
+</screen>
+
+      <para>In this example, Sally can see not only that her copy of
+        <filename>foo.h</filename> is out-of-date, but that one of the
+        two modified files she plans to commit is locked in the
+        repository.  The <literal>O</literal> symbol stands for
+        <quote>Other</quote>, meaning that a lock exists on the file,
+        and was created by somebody else.  If she were to attempt a
+        commit, the lock on <filename>raisin.jpg</filename> would
+        prevent it.  Sally is left wondering who made the lock, when,
+        and why.  Once again, <command>svn info</command> has the
+        answers:</para>
+
+      <screen>
+$ svn info http://svn.example.com/repos/project/raisin.jpg
+Path: raisin.jpg
+Name: raisin.jpg
+URL: http://svn.example.com/repos/project/raisin.jpg
+Repository UUID: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
+Revision: 105
+Node Kind: file
+Last Changed Author: sally
+Last Changed Rev: 32
+Last Changed Date: 2005-01-25 12:43:04 -0600 (Tue, 25 Jan 2005)
+Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
+Lock Owner: harry
+Lock Created: 2005-02-16 13:29:18 -0500 (Wed, 16 Feb 2005)
+Lock Comment (1 line):
+Need to make a quick tweak to this image.
+</screen>
+
+      <para>Just as <command>svn info</command> can be used to examine
+        objects in the working copy, it can also be used to examine
+        objects in the repository.  If the main argument to
+        <command>svn info</command> is a working copy path, then all
+        of the working copy's cached information is displayed;  any
+        mention of a lock means that the working copy is holding a
+        lock token.  If the main argument to <command>svn
+        info</command> is a URL, then the information reflects the
+        latest version of an object in the repository;  any mention of
+        a lock describes the current lock on the object.</para>
+
+      <para>So in this particular example, Sally can see that Harry
+        locked the file on Feburary 16th to <quote>make a quick
+        tweak</quote>.  It being June, she suspects that he probably
+        forgot all about the lock.  She might phone Harry to complain
+        and ask him to release the lock.  If he's unavailable, she
+        might try to forcibly break the lock herself or ask an
+        administrator to do so.</para>
+
+    </sect2>
+
+    <sect2 id="svn.advanced.locking.break-steal">
+      <title>Breaking and stealing locks</title>
+
+      <para>A repository lock isn't sacred; it can be released not
+        only by the person who created it, but by anyone at all.  When
+        somebody other than the original lock creator destroys a lock,
+        we refer to this as <firstterm>breaking</firstterm> the
+        lock.</para>
+
+      <para>From the administrator's chair, it's simple to break
+        locks.  The <command>svnlook</command>
+        and <command>svnadmin</command> programs have the ability to
+        display and remove locks directly from the repository.  (For
+        more information about these tools, see
+        <xref linkend="svn.reposadmin.maint.tk"/>.)</para>
+
+      <screen>
+$ svnadmin lslocks /usr/local/svn/repos
+Path: /project2/images/banana.jpg
+UUID Token: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
+Owner: frank
+Created: 2005-06-15 13:29:18 -0500 (Wed, 15 Jun 2005)
+Expires: 
+Comment (1 line):
+Still improving the yellow color.
+
+Path: /project/raisin.jpg
+UUID Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
+Owner: harry
+Created: 2005-02-16 13:29:18 -0500 (Wed, 16 Feb 2005)
+Expires: 
+Comment (1 line):
+Need to make a quick tweak to this image.
+
+$ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
+Removed lock on '/project/raisin.jpg'.
+</screen>
+
+      <para>The more interesting option is allowing users to break
+        each other's locks over the network.  To do this, one simply
+        needs to pass the <option>--force</option> to the unlock
+        command:</para>
+
+      <screen>
+$ whoami
+sally
+
+$ svn status --show-updates
+M              23   bar.c
+M    O         32   raisin.jpg
+       *       72   foo.h
+Status against revision:     105
+
+$ svn unlock raisin.jpg
+svn: 'raisin.jpg' is not locked in this working copy
+
+$ svn info raisin.jpg | grep URL
+URL: http://svn.example.com/repos/project/raisin.jpg
+
+$ svn unlock http://svn.example.com/repos/project/raisin.jpg
+svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
+
+$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
+'raisin.jpg' unlocked.
+</screen>
+
+      <para>Sally's initial attempt to unlock failed because she
+        ran <command>svn unlock</command> directly on her working copy
+        of the file, and no lock token was present.  To remove the
+        lock directly from the repository, she needs to pass a URL
+        to <command>svn unlock</command>.  Her first attempt to unlock
+        the URL fails, because she can't authenticate as the lock
+        owner (nor does she have the lock token).  But when she
+        passes <option>--force</option>, the authentication and
+        authorization requirements are ignored, and the remote lock is
+        broken.</para>
+        
+      <para>Of course, simply breaking a lock may not be enough.  In
+        the running example, Sally may not only want to break Harry's
+        long-forgotten lock, but re-lock the file for her own use.
+        She can accomplish this by running <command>svn unlock
+        --force</command> and then <command>svn lock</command>
+        back-to-back, but there's a small chance that somebody else
+        might lock the file between the two commands.  The simpler thing
+        to is <firstterm>steal</firstterm> the lock, which involves
+        breaking and re-locking the file all in one atomic step.  To
+        do this, pass the <option>--force</option> option
+        to <command>svn lock</command>:</para>
+
+        <screen>
+$ svn lock raisin.jpg
+svn: Lock request failed: 423 Locked (http://svn.example.com)
+
+$ svn lock --force raisin.jpg
+'raisin.jpg' locked by user 'sally'.
+</screen>
+
+        <para>In any case, whether the lock is broken or stolen, Harry
+          may be in for a surprise.  Harry's working copy still
+          contains the original lock token, but that lock no longer
+          exists.  The lock token is said to
+          be <firstterm>defunct</firstterm>.  The lock represented by
+          the lock-token has either been broken (no longer in the
+          repository), or stolen (replaced with a different lock).
+          Either way, Harry can see this by asking <command>svn
+          status</command> to contact the repository:</para>
+
+        <screen>
+$ whoami
+harry
+
+$ svn status
+     K raisin.jpg
+
+$ svn status --show-updates
+     B         32   raisin.jpg
+
+$ svn update
+  B  raisin.jpg
+
+$ svn status
+
+$
+</screen>
+
+        <para>If the repository lock was broken, then <command>svn
+            status --show-updates</command> displays
+            a <literal>B</literal> (Broken) symbol next to the file.
+            If a new lock exists in place of the old one, then
+            a <literal>T</literal> (sTolen) symbol is shown.
+            Finally, <command>svn update</command> notices any defunct
+            lock tokens and removes them from the working copy.</para>
+
+        <sidebar>
+          <title>Locking Policies</title>
+        
+          <para>Different systems have different notions of how strict
+            a lock should be.  Some folks argue that locks must be
+            strictly enforced at all costs, releasable only by the
+            original creator or administrator.  They argue that if
+            anyone can break a lock, then chaos breaks loose and the
+            whole point of locking is defeated.  The other side argues
+            that locks are first and foremost a communication tool.
+            If users are constantly breaking each others' locks, then
+            it represents a cultural failure within the team and the
+            problem falls outside the scope of software
+            enforcement.</para>
+
+          <para>Subversion defaults to the <quote>softer</quote>
+            approach, but still allows administrators to create
+            stricter enforcement policies through the use of hook
+            scripts.  In particular, the <filename>pre-lock</filename>
+            and <filename>pre-unlock</filename> hooks allow
+            administrators to decide when lock creation and lock
+            releases are allowed to happen.  Depending on whether or
+            not a lock already exists, these two hooks can decide
+            whether or not to allow a certain user to break or steal a
+            lock.  The <filename>post-lock</filename>
+            and <filename>post-unlock</filename> hooks are also
+            available, and can be used to send email after locking
+            actions.</para>
+
+          <para>To learn more about repository hooks, see
+            <xref linkend="svn.reposadmin.create.hooks"/>.</para>
+        </sidebar>
+
+    </sect2>
+
+    <sect2 id="svn.advanced.locking.lock-communication">
+      <title>Lock Communication</title>
+
+      <para>We've seen how <command>svn lock</command>
+        and <command>svn unlock</command> can be used to create,
+        release, break, and steal locks.  This satisifies the goal of
+        serializing commit access to a file.  But what about the
+        larger problem of preventing wasted time?</para>
+
+      <para>For example, suppose Harry locks an image file and then
+        begins editing it.  Meanwhile, miles away, Sally wants to do
+        the same thing.  She doesn't think to run <command>svn status
+        --show-updates</command>, so she has no idea that Harry has
+        already locked the file.  She spends hours editing the file,
+        and when she tries to commit her change, she discovers that
+        either the file is locked or that she's out-of-date.
+        Regardless, her changes aren't mergeable with Harry's.  One of
+        these two people has to throw away their work, and a lot of
+        time has been wasted.</para>
+      
+      <para>Subversion's solution to this problem is provide a
+        mechanism to remind users that a file ought to be locked
+        <emphasis>before</emphasis> the editing begins.</para>
+
+      <para>The mechanism is a special
+        property, <literal>svn:needs-lock</literal>.  If the property
+        is attached to a file (the value is irrelevant), then the file
+        will have read-only permissions.  When the user locks the file
+        and receives a lock token, the file becomes read-write.  When
+        the lock is released—either explicitly unlocked, or
+        released via commit—the file returns to read-only
+        again.</para>
+      
+      <para>The theory, then, is that if the image file has this
+        property attached, then Sally would immediately notice
+        something is strange when she opens the file for editing.  Her
+        application would be unable to save changes, or (better yet)
+        tell her that the file is read-only.  This reminds her to lock
+        the file before editing, whereby she discovers the
+        pre-existing lock:</para>
+
+      <screen>
+$ /usr/local/bin/gimp raisin.jpg
+gimp: error: file is read-only!
+
+$ ls -l raisin.jpg
+-r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
+
+$ svn lock raisin.jpg
+svn: Lock request failed: 423 Locked (http://svn.example.com)
+
+$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
+Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
+Lock Owner: harry
+Lock Created: 2005-06-08 07:29:18 -0500 (Thu, 08 June 2005)
+Lock Comment (1 line):
+Making some tweaks.  Locking for the next two hours.
+
+</screen>
+
+        <para>As a matter of <quote>best practice</quote>, both users
+          and administrators are encouraged to attach
+          the <literal>svn:needs-lock</literal> property to any file
+          which cannot be contextually merged.  It's the main
+          technique for encouraging good locking habits and preventing
+          wasted effort.</para>
+
+        <para>Note that this property is a communication tool which
+          works independently from the locking system.  In other
+          words, any file can be locked, whether or not this property
+          is present.  And conversely, the presence of this property
+          doesn't make the repository require a lock when
+          committing.</para>
+
+        <para>The system isn't flawless, either.  It's possible that
+          even when a file has the property, the read-only reminder
+          won't always work.  Sometimes applications misbehave and
+          <quote>hijack</quote> the read-only file, silently allowing
+          users to edit and save the file anyway.  Unfortunately,
+          there's not much Subversion can do about this.</para>
+
+    </sect2>
 
   </sect1>
 
@@ -2159,6 +2697,12 @@
       <command>svn switch --relocate</command>), externals definitions
       will <emphasis>not</emphasis> also be re-parented.</para>
 
+    <para>Finally, there might be times when you would prefer that
+      <command>svn</command> subcommands would not recognize or
+      otherwise operate on the external working copies created as the
+      result of externals definition handling.  In those instances,
+      you can pass the <option>--ignore-externals</option> option to
+      the subcommand.</para>
   </sect1>
 
   <!-- ******************************************************************* -->

Modified: trunk/src/nb/book/ch09.xml
==============================================================================
--- trunk/src/nb/book/ch09.xml	(original)
+++ trunk/src/nb/book/ch09.xml	Fri Jun 17 15:50:26 2005
@@ -203,6 +203,14 @@
         </varlistentry>
       
         <varlistentry>
+          <term><option>--ignore-externals</option></term>
+          <listitem>
+            <para>Tells Subversion to ignore external definitions and
+              the external working copies managed by them.</para>
+          </listitem>
+        </varlistentry>
+      
+        <varlistentry>
           <term><option>--incremental</option></term>
           <listitem>
             <para>Prints output in a format suitable for
@@ -577,7 +585,7 @@
 A         foo.c
 A         somedir/bar.c
 A         otherdir/docs/baz.doc
-[...]
+…
 </screen>
 
         </refsect1>
@@ -873,8 +881,7 @@
             locks resuming unfinished operations.  If you ever get a
             <quote>working copy locked</quote> error, run this
             command to remove stale locks and get your working copy
-            into a usable state again.  See <xref
-            linkend="svn.tshoot"/>.</para>
+            into a usable state again.</para>
 
           <para>If, for some reason, an <command>svn update</command>
             fails due to a problem running an external diff program
@@ -1637,6 +1644,7 @@
 --non-interactive
 --config-dir DIR
 --native-eol EOL
+--ignore-externals
 </screen>
         </refsect1>
 
@@ -1781,6 +1789,7 @@
 --config-dir DIR
 --auto-props
 --no-auto-props
+--ignore-externals
 </screen>
         </refsect1>
 
@@ -3453,6 +3462,7 @@
 --no-auth-cache
 --non-interactive
 --config-dir
+--ignore-externals
 </screen>
         </refsect1>
 
@@ -3763,6 +3773,7 @@
 --no-auth-cache
 --non-interactive
 --config-dir DIR
+--ignore-externals
 </screen>
         </refsect1>
 
@@ -3917,6 +3928,26 @@
               errors.</para>
           </listitem>
         </varlistentry>
+
+        <varlistentry>
+          <term><option>--use-post-commit-hook</option></term>
+          <listitem>
+            <para>When loading a dump file, run the repository's
+              post-commit hook after finalizing each newly loaded
+              revision.</para>
+          </listitem>
+        </varlistentry>
+
+        <varlistentry>
+          <term><option>--use-pre-commit-hook</option></term>
+          <listitem>
+            <para>When loading a dump file, run the repository's
+              pre-commit hook before finalizing each newly loaded
+              revision.  If the hook fails, abort the commit and
+              terminate the load process.</para>
+          </listitem>
+        </varlistentry>
+
       </variablelist>
     </sect2>
 
@@ -4249,6 +4280,8 @@
 --quiet (-q)
 --ignore-uuid
 --force-uuid
+--use-pre-commit-hook
+--use-post-commit-hook
 --parent-dir
 </screen>
         </refsect1>



More information about the svnbook-dev mailing list