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

sunny256 noreply at red-bean.com
Thu Jul 17 03:04:42 CDT 2008


Author: sunny256
Date: Thu Jul 17 03:04:42 2008
New Revision: 3203

Log:
Sync the Norwegian and English book: "make sync HEAD=2656".

* src/nb/book/ch-advanced-topics.xml
* src/nb/book/ch-branching-and-merging.xml
* src/nb/book/ch-customizing-svn.xml
* src/nb/book/ch-server-configuration.xml
* src/nb/LAST_SYNC
* src/nb/TRANSLATION-STATUS
  Merged, resolved and updated r2653, r2654, r2655, r2656.


Modified:
   trunk/src/nb/LAST_SYNC
   trunk/src/nb/TRANSLATION-STATUS
   trunk/src/nb/book/ch-advanced-topics.xml
   trunk/src/nb/book/ch-branching-and-merging.xml
   trunk/src/nb/book/ch-customizing-svn.xml
   trunk/src/nb/book/ch-server-configuration.xml

Modified: trunk/src/nb/LAST_SYNC
==============================================================================
--- trunk/src/nb/LAST_SYNC	(original)
+++ trunk/src/nb/LAST_SYNC	Thu Jul 17 03:04:42 2008
@@ -1 +1 @@
-2652
+2656

Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS	(original)
+++ trunk/src/nb/TRANSLATION-STATUS	Thu Jul 17 03:04:42 2008
@@ -18,19 +18,19 @@
 * book/ch-basic-usage.xml
     Untranslated: 4.31% - 108 lines in 8 blocks
 * book/ch-advanced-topics.xml
-    Untranslated: 77.06% - 2157 lines in 8 blocks
-    Need proofreading: 18.98% - 567 lines in 2 blocks
+    Untranslated: 71.31% - 2201 lines in 11 blocks
+    Need proofreading: 17.27% - 567 lines in 2 blocks
 * book/ch-branching-and-merging.xml
-    Untranslated: 5.06% - 125 lines in 1 block
-    Need proofreading: 10.22% - 242 lines in 1 block
+    Untranslated: 5.07% - 125 lines in 1 block
+    Need proofreading: 10.23% - 242 lines in 1 block
 * book/ch-repository-admin.xml
     Untranslated: 2.84% - 131 lines in 9 blocks
 * book/ch-server-configuration.xml
-    Untranslated: 23.52% - 745 lines in 17 blocks
-    Need proofreading: 66.45% - 2004 lines in 6 blocks
+    Untranslated: 25.72% - 728 lines in 15 blocks
+    Need proofreading: 72.78% - 1990 lines in 6 blocks
 * book/ch-customizing-svn.xml
-    Untranslated: 35.66% - 412 lines in 2 blocks
-    Need proofreading: 63.98% - 711 lines in 1 block
+    Untranslated: 35.65% - 412 lines in 2 blocks
+    Need proofreading: 63.99% - 713 lines in 1 block
 * book/ch-developer-info.xml
     Untranslated: 100.00% - 1427 lines in 1 block
 * book/ch-reference.xml
@@ -49,4 +49,4 @@
 * book/index.xml
     Translation complete
 
-Summa summarum: 56.06% translated, 16.38% need proofreading
+Summa summarum: 55.95% translated, 16.29% need proofreading

Modified: trunk/src/nb/book/ch-advanced-topics.xml
==============================================================================
--- trunk/src/nb/book/ch-advanced-topics.xml	(original)
+++ trunk/src/nb/book/ch-advanced-topics.xml	Thu Jul 17 03:04:42 2008
@@ -72,6 +72,11 @@
 <!-- @TR {{ -->
     <title>Revision Specifiers</title>
 
+    <indexterm>
+      <primary>revisions</primary>
+      <secondary>specifying</secondary>
+    </indexterm>
+
     <para>As you saw in <xref linkend="svn.tour.revs" />, revision
       numbers in Subversion are pretty straightforward—integers
       that keep getting larger as you commit more changes to your
@@ -116,6 +121,41 @@
       <title>Nøkkelord for revisjoner</title>
       
       <!-- @ENGLISH {{{
+      <indexterm>
+        <primary>revisions</primary>
+        <secondary>revision keywords</secondary>
+      </indexterm>
+      <indexterm>
+        <primary>HEAD</primary>
+      </indexterm>
+      <indexterm>
+        <primary>BASE</primary>
+      </indexterm>
+      <indexterm>
+        <primary>COMMITTED</primary>
+      </indexterm>
+      <indexterm>
+        <primary>PREV</primary>
+      </indexterm>
+      @ENGLISH }}} -->
+      <indexterm>
+        <primary>revisjoner</primary>
+        <secondary>revisjonsnøkkelord</secondary>
+      </indexterm>
+      <indexterm>
+        <primary>HEAD</primary>
+      </indexterm>
+      <indexterm>
+        <primary>BASE</primary>
+      </indexterm>
+      <indexterm>
+        <primary>COMMITTED</primary>
+      </indexterm>
+      <indexterm>
+        <primary>PREV</primary>
+      </indexterm>
+
+      <!-- @ENGLISH {{{
       <para>The Subversion client understands a number of
         <firstterm>revision keywords</firstterm>.  These keywords can
         be used instead of integer arguments to the
@@ -270,6 +310,17 @@
       @ENGLISH }}} -->
       <title>Revisjonsdatoer</title>
       
+      <!-- @ENGLISH {{{
+      <indexterm>
+        <primary>revisions</primary>
+        <secondary>specified as dates</secondary>
+      </indexterm>
+      @ENGLISH }}} -->
+      <indexterm>
+        <primary>revisjoner</primary>
+        <secondary>spesifisert som datoer</secondary>
+      </indexterm>
+
 <!-- @TR {{ -->
       <para>Revision numbers reveal nothing about the world outside
         the version control system, but sometimes you need to
@@ -448,8 +499,14 @@
   <sect1 id="svn.advanced.props">
     <!-- @ENGLISH {{{
     <title>Properties</title>
+    <indexterm>
+      <primary>properties</primary>
+    </indexterm>
     @ENGLISH }}} -->
     <title>Egenskaper</title>
+    <indexterm>
+      <primary>egenskaper</primary>
+    </indexterm>
 
 <!-- @CHK {{ -->
     <!-- @ENGLISH {{{
@@ -3587,6 +3644,524 @@
 
   </sect1>
 
+  <!-- ================================================================= -->
+  <!-- ================================================================= -->
+  <!-- ================================================================= -->
+  <sect1 id="svn.advanced.netmodel">
+
+    <!-- @ENGLISH {{{
+    <title>Network Model</title>
+    @ENGLISH }}} -->
+    <title>Nettverksmodellen</title>
+
+<!-- @TR {{ -->
+    <para>At some point, you're going to need to understand how your
+      Subversion client communicates with its server.  Subversion's
+      networking layer is abstracted, meaning that the Subversion
+      client exhibits the same general behaviors no matter what sort
+      of server it speaks with.  Whether it's talking to Apache
+      via <literal>http://</literal> or
+      with <literal>svnserve</literal> via <literal>svn://</literal>,
+      it responds to authentication challenges in the same ways, and
+      even caches your login name and password for you.  This section
+      discusses these behaviors and shows you how to manage them to
+      your liking.</para>
+<!-- @TR }} -->
+
+    <!-- =============================================================== -->
+    <sect2 id="svn.advanced.netmodel.reqresp">
+      <!-- @ENGLISH {{{
+      <title>Requests and Responses</title>
+      @ENGLISH }}} -->
+      <title>Forespørsler og reponser</title>
+
+      <!-- @ENGLISH {{{
+      <para>The Subversion client spends most of its time managing
+        working copies.  When it needs information from a repository,
+        however, it makes a network request, and the server responds
+        with an appropriate answer.  The details of the network
+        protocol are hidden from the user; the client attempts to
+        access a URL, and depending on the URL schema, a particular
+        protocol is used to contact the server (see <xref
+        linkend="svn.basic.in-action.wc.sb-1"/>).  Users can run <command>svn
+        -ﳢ-version</command> to see which URL schemas and protocols the
+        client knows how to use.</para>
+      @ENGLISH }}} -->
+      <para>Subversionklienten bruker mesteparten av tida til å behandle 
+        arbeidskopier.
+        Men når den trenger informasjon fra et depot foretar den en 
+        nettverksforespørsel og &the_server; kommer med et passende 
+        svar.
+        Detaljene i nettverksprotokollen er skjult for brukeren; 
+        klienten prøver å aksessere en URL, og alt etter hvilket 
+        URL-skjema som brukes blir en passende protokoll brukt for å 
+        aksessere &the_server; (se <xref 
+        linkend="svn.basic.in-action.wc.sb-1"/>).
+        Brukere kan kjøre <command>svn --version</command> for å se 
+        hvilke URL-skjema og protokoller klienten kan bruke.</para>
+
+      <!-- @ENGLISH {{{
+      <para>When the server process receives a client request, it
+        typically demands that the client identify itself.  It issues
+        an authentication challenge to the client, and the client
+        responds by providing <firstterm>credentials</firstterm> back
+        to the server.  Once authentication is complete, the server
+        responds with the original information the client asked for.
+        Notice that this system is different from systems like CVS,
+        where the client pre-emptively offers credentials (<quote>logs
+        in</quote>) to the server before ever making a request.  In
+        Subversion, the server <quote>pulls</quote> credentials by
+        challenging the client at the appropriate moment, rather than
+        the client <quote>pushing</quote> them.  This makes certain
+        operations more elegant.  For example, if a server is
+        configured to allow anyone in the world to read a repository,
+        then the server will never issue an authentication challenge
+        when a client attempts to <command>svn
+        checkout</command>.</para>
+      @ENGLISH }}} -->
+      <para>Når &the_server; mottar en klientforespørsel, forlanger den 
+        vanligvis at klienten identifiserer seg.
+        Den utsteder en autentiseringsforespørsel til klienten, og 
+        klienten svarer ved å <firstterm>legitimere</firstterm> seg 
+        ovenfor &the_server;.
+        Når autentiseringen er komplett, svarer &the_server; med den 
+        originale informasjonen klienten spurte etter.
+        Legg merke til at dette systemet er forskjellig fra systemer som 
+        CVS, hvor klienten på forhånd oppgir legitimasjon (<quote>logger 
+        inn</quote>) til &the_server; før noen forespørsel etter 
+        informasjon blir gjort.
+        I Subversion <quote>henter</quote> &the_server; legitimasjonen 
+        ved å kontrollere klienten på det nødvendige tidspunktet i 
+        stedet for at klienten uoppfordret <quote>leverer</quote> den.
+        Dette gjør visse operasjoner mer elegant.
+        For eksempel, hvis en &server; er konfigurert til å la alle i 
+        hele verden få lese depotet, vil &the_server; aldri be om 
+        autentisering når klienten prøver en <command>svn 
+        checkout</command>.</para>
+
+      <!-- @ENGLISH {{{
+      <para>If the client's network request writes new data to the
+        repository (e.g. <command>svn commit</command>), then a new
+        revision tree is created.  If the client's request was
+        authenticated, then the authenticated user's name is stored as
+        the value of the <literal>svn:author</literal> property on the
+        new revision (see <xref linkend="svn.reposadmin.basics.revprops"/>).  If
+        the client was not authenticated (in other words, the server
+        never issued an authentication challenge), then the revision's
+        <literal>svn:author</literal> property is empty.
+        <footnote><para>This problem is actually a FAQ, resulting from
+        a misconfigured server setup.</para></footnote></para>
+      @ENGLISH }}} -->
+      <para>Hvis klientens nettverksforespørsel skriver nye data til 
+        depotet (for eksempel <command>svn commit</command>), vil et 
+        nytt revisjonstre bli opprettet.
+        Hvis klientens forespøsel ble autentisert, blir brukernavnet til 
+        den autentiserte brukeren lagret i 
+        <literal>svn:author</literal>-egenskapen i den nye revisjonen 
+        (se <xref linkend="svn.reposadmin.basics.revprops"/>).
+        Hvis klienten ikke ble autentisert (med andre ord, &the_server; 
+        spurte ikke etter legitimasjon), er revisjonens 
+        <literal>svn:author</literal>-egenskap tom.<footnote>
+          <para>Dette er egentlig et spørsmål som ofte dukker opp som et 
+            resultat av feil i konfigurasjonen på &the_server;.</para>
+        </footnote></para>
+
+    </sect2>
+
+    <!-- =============================================================== -->
+    <sect2 id="svn.advanced.netmodel.credcache">
+      <!-- @ENGLISH {{{
+      <title>Client Credentials Caching</title>
+      @ENGLISH }}} -->
+      <title>Lagring av klientlegitimasjon</title>
+
+      <!-- @ENGLISH {{{
+      <para>Many servers are configured to require authentication on
+        every request.  This can become a big annoyance to users, who
+        are forced to type their passwords over and over again.</para>
+      @ENGLISH }}} -->
+      <para>Mange &servers; er satt opp til å forlange autentisering for 
+        hver eneste forespørsel.
+        Dette kan bli et stort irritasjonsmoment for brukerne, som blir 
+        tvunget til å skrive passordet om og om igjen.</para>
+
+      <!-- @ENGLISH {{{
+      <para>Happily, the Subversion client has a remedy for this: a
+        built-in system for caching authentication credentials on
+        disk.  By default, whenever the command-line client
+        successfully responds to a server's authentication challenge,
+        it saves the credentials in the user's private runtime
+        configuration
+        area—in <filename>~/.subversion/auth/</filename> on
+        Unix-like systems or
+        <filename>%APPDATA%/Subversion/auth/</filename> on Windows.
+        (The runtime area is covered in more detail in <xref
+        linkend="svn.advanced.confarea"/>.)  Successful credentials are
+        cached on disk, keyed on a combination of hostname, port, and
+        authentication realm.</para>
+      @ENGLISH }}} -->
+      <para>Heldigvis har Subversion en løsning på dette:
+        Et innebygget system for å lagre legitimasjonen på disk.
+        Normalt sett, når kommandolinjeklienten klarer å svare riktig på 
+        en autentiseringsforespørsel fra en &server;, lagres denne 
+        legitimasjonsinformasjonen i brukerens private <!-- ¤ runtime 
+        -->konfigurasjonsområde – i 
+        <filename>~/.subversion/auth/</filename> på Unix-lignende 
+        systemer eller <filename>%APPDATA%/Subversion/auth/</filename> i 
+        Windows.
+        (<!-- ¤ runtime igjen – fellesordlista til Skolelinux oversetter 
+        dette med «kjøretid», men … vel. I dette tilfellet passer det 
+        vel bedre å ikke ha det med. -->Konfigurasjonsområdet er dekket 
+        mer inngående i <xref linkend="svn.advanced.confarea"/>.)
+        Data fra vellykkede autentiseringer lagres på disken, der 
+        nøkkelen er en kombinasjon av &server;navn, port og området der 
+        autentiseringen gjelder.</para>
+
+      <!-- @ENGLISH {{{
+      <para>When the client receives an authentication challenge, it
+        first looks for the appropriate credentials in the user's disk
+        cache; if not present, or if the cached credentials fail to
+        authenticate, then the client simply prompts the user for the
+        information.</para>
+      @ENGLISH }}} -->
+      <para>Når klienten må gjennom en autentiseringsprosess, ser den 
+        først etter passende legitimasjonsdata i brukerens lager på 
+        disken.
+        Hvis dette ikke finnes, eller de lagrede legitimasjonsdataene 
+        ikke er tilstrekkelig for å fullføre autentiseringen, spør 
+        klienten ganske enkelt brukeren etter informasjonen.</para>
+
+      <!-- @ENGLISH {{{
+      <para>Security-conscious people may be thinking to themselves,
+        <quote>Caching passwords on disk?  That's terrible!  You
+        should never do that!</quote> Please remain calm, it's not as
+        dangerous as it sounds.</para>
+      @ENGLISH }}} -->
+      <para>Sikkerhetsbevisste folk tenker nok med seg selv:
+        <quote>Lagre passord på disken?
+        Det er forferdelig!
+        Sånt skal aldri gjøres!</quote>
+        Men ta det med ro, det er ikke så farlig som det høres 
+        ut.</para>
+
+      <itemizedlist>
+
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>On Windows 2000 and later, the Subversion client uses
+            standard Windows cryptography services to encrypt the
+            password on disk.  Because the encryption key is managed
+            by Windows and is tied to the user's own login
+            credentials, only the user can decrypt the cached
+            password.  (Note: if the user's Windows account password
+            is reset by an administrator, all of the cached passwords
+            become undecipherable.  The Subversion client will behave
+            as if they don't exist, prompting for passwords when
+            required.)</para>
+          @ENGLISH }}} -->
+          <para>På Windows 2000 og senere bruker Subversionklienten 
+            standard kryptografitjenester i Windows for å kryptere 
+            passordet på disken.
+            Fordi krypteringsnøkkelen blir vedlikeholdt av Windows og 
+            den er forbundet med brukerens egne <!-- ¤ credentials 
+            -->innloggingsbrukerdata, kan bare brukeren dekryptere det 
+            lagrede passordet.
+            (Merk:
+            Hvis brukerens passord i Windows blir resatt av en 
+            administrator, kan ikke de lagrede passordene dekrypteres.
+            Subversionklienten vil oppføre seg som om de ikke eksisterer 
+            og spørre etter passord når det er nødvendig.)</para>
+        </listitem>
+
+<!-- @TR {{ -->
+        <listitem>
+          <para>Similarly, on Mac OS X, the Subversion client stores
+            all repository passwords in the login keyring (managed by
+            the Keychain service), which is protected by the user's
+            account password.  User preference settings can impose
+            additional policies, such as requiring the user's account
+            password be entered each time the Subversion password is
+            used.</para>
+        </listitem>
+<!-- @TR }} -->
+
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>For other Unix-like operating systems, no standard
+            <quote>keychain</quote> services exist.  However,
+            the <filename>auth/</filename> caching area is still
+            permission-protected so that only the user (owner) can
+            read data from it, not the world at large.  The operating
+            system's own file permissions are protecting the
+            password.</para>
+          @ENGLISH }}} -->
+          <para>For andre Unix-lignende operativsystemer eksisterer det 
+            ingen standardiserte <quote>nøkkelring</quote>-tjenester.
+            Imidlertid er lagringsområdet i <filename>auth/</filename> 
+            fortsatt beskyttet av rettigheter så bare brukeren (eieren) 
+            kan lese dataene derfra, ikke resten av verden.
+            Operativsystemets egne filrettigheter beskytter 
+            passordet.</para>
+        </listitem>
+
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>For the truly paranoid willing to sacrifice
+            convenience, it's always possible to disable credential
+            caching altogether.</para>
+          @ENGLISH }}} -->
+          <para>For den sanne paranoide som er villig til å ofre 
+            behageligheter, er det alltids mulig å deaktivere all 
+            lagring av legitimasjonsdata.</para>
+        </listitem>
+
+      </itemizedlist>
+
+      <!-- @ENGLISH {{{
+      <para>To disable caching for a single command, pass the
+        <option>-ﳢ-no-auth-cache</option> option:</para>
+      @ENGLISH }}} -->
+      <para>For å forhindre lagring for en enkelt kommando, spesifiser 
+        valget <option>--no-auth-cache</option>:</para>
+
+      <!-- @ENGLISH {{{
+      <screen>
+$ svn commit -F log_msg.txt -ﳢ-no-auth-cache
+Authentication realm: <svn://host.example.com:3690> example realm
+Username:  joe
+Password for 'joe':
+
+Adding         newfile
+Transmitting file data .
+Committed revision 2324.
+
+# password was not cached, so a second commit still prompts us
+
+$ svn delete newfile
+$ svn commit -F new_msg.txt
+Authentication realm: <svn://host.example.com:3690> example realm
+Username:  joe
+…
+</screen>
+      @ENGLISH }}} -->
+<!-- @TR {{ -->
+      <screen>
+$ svn commit -F log_msg.txt --no-auth-cache
+Authentication realm: <svn://host.example.com:3690> example realm
+Username:  joe
+Password for 'joe':
+
+Adding         newfile
+Transmitting file data .
+Committed revision 2324.
+
+# Passordet ble ikke lagret, så ved neste innlegging blir vi spurt på 
+# nytt.
+
+$ svn delete newfile
+$ svn commit -F new_msg.txt
+Authentication realm: <svn://host.example.com:3690> example realm
+Username:  joe
+…
+</screen>
+<!-- @TR }} -->
+
+      <!-- @ENGLISH {{{
+      <para>Or, if you want to disable credential caching permanently,
+        you can edit your runtime <filename>config</filename> file
+        (located next to the <filename>auth/</filename> directory).
+        Simply set <literal>store-auth-creds</literal> to
+        <literal>no</literal>, and no credentials will be cached on
+        disk, ever.</para>
+      @ENGLISH }}} -->
+      <para>Eller, hvis du vil slå av lagring av legitimasjonen 
+        permanent, kan du redigere <filename>config</filename>-fila 
+        (plassert ved siden av <filename>auth/</filename>-katalogen).
+        Ved å sette <literal>store-auth-creds</literal> til 
+        <literal>no</literal> vil ingen legitimasjon bli lagret på 
+        disken i det hele tatt.</para>
+
+      <screen>
+[auth]
+store-auth-creds = no
+</screen>
+
+      <!-- @ENGLISH {{{
+      <para>Sometimes users will want to remove specific credentials
+        from the disk cache.  To do this, you need to navigate into
+        the <filename>auth/</filename> area and manually delete the
+        appropriate cache file.  Credentials are cached in individual
+        files;  if you look inside each file, you will see keys and
+        values.  The <literal>svn:realmstring</literal> key describes
+        the particular server realm that the file is associated
+        with:</para>
+      @ENGLISH }}} -->
+      <para>Noen ganger vil brukere ønske å fjerne spesifikke 
+        legitimasjonsdata fra disklageret.
+        For å gjøre dette, må du gå inn i 
+        <filename>auth/</filename>-området og manuelt slette den 
+        aktuelle fila.
+        Legitimasjonen er lagret i individuelle filer, og hvis du ser på 
+        hver fil, vil du se nøkler og verdier.
+        <literal>svn:realmstring</literal>-nøkkelen viser hvilket 
+        &server;område fila er assosiert med:</para>
+
+      <screen>
+$ ls ~/.subversion/auth/svn.simple/
+5671adf2865e267db74f09ba6f872c28
+3893ed123b39500bca8a0b382839198e
+5c3c22968347b390f349ff340196ed39
+
+$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28
+
+K 8
+username
+V 3
+joe
+K 8
+password
+V 4
+blah
+K 15
+svn:realmstring
+V 45
+<https://svn.domain.com:443> Joe's repository
+END
+</screen>
+
+      <!-- @ENGLISH {{{
+      <para>Once you have located the proper cache file, just delete
+        it.</para>
+      @ENGLISH }}} -->
+      <para>Når du har funnet den riktige fila, er det bare å slette 
+        den.</para>
+
+      <!-- @ENGLISH {{{
+      <para>One last word about client authentication behavior: a bit
+        of explanation about the <option>-ﳢ-username</option> and
+        <option>-ﳢ-password</option> options is needed.  Many client
+        subcommands accept these options; however it is important to
+        understand using these options <emphasis>does not</emphasis>
+        automatically send credentials to the server.  As discussed
+        earlier, the server <quote>pulls</quote> credentials from the
+        client when it deems necessary; the client cannot
+        <quote>push</quote> them at will.  If a username and/or
+        password are passed as options, they will
+        <emphasis>only</emphasis> be presented to the server if the
+        server requests them.
+
+         <footnote><para>Again, a common mistake is to misconfigure a
+           server so that it never issues an authentication challenge.
+           When users pass <option>-ﳢ-username</option> and
+           <option>-ﳢ-password</option> options to the client,
+           they're surprised to see that they're never used, i.e. new
+           revisions still appear to have been committed
+           anonymously!</para></footnote>
+
+        Typically, these options are used when:</para>
+      @ENGLISH }}} -->
+      <para>Et siste ord om oppførselen under klientautentisering, en 
+        liten forklaring angående <option>--username</option> og 
+        <option>--password</option> er på sin plass.
+        Mange delkommandoer for klienten godtar disse valgene, men det 
+        er viktig å forstå at bruken av disse valgene sender 
+        <emphasis>ikke</emphasis> brukerdata til &the_server;.
+        Som tidligere nevnt, <quote>henter</quote> &the_server; 
+        brukerdata fra klienten når det er nødvendig; klienten kan ikke 
+        <quote>levere</quote> dataene når den vil.
+        Hvis et brukernavn og/eller passord blir spesifisert som valg, 
+        vil de <emphasis>bare</emphasis> bli gitt til &the_server; hvis 
+        &the_server; spør etter dem.<footnote>
+          <para>Som sagt, en vanlig feil er å feilkonfigurere 
+            &the_server; så den aldri spør etter autentiseringsinfo.
+            Når brukere angir <option>--username</option> og 
+            <option>--password</option> til klienten, blir de overrasket 
+            over å se at dataene aldri blir brukt og at nye revisjoner 
+            fortsatt ser ut til å ha blitt lagt inn anonymt!</para>
+        </footnote>
+        Vanligvis blir disse valgene brukt når:</para>
+
+      <itemizedlist>
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>the user wants to authenticate as a different user
+            than her system login name, or</para>
+          @ENGLISH }}} -->
+          <para>brukeren vil identifisere seg som en annen bruker enn 
+            brukernavnet på systemet, eller</para>
+        </listitem>
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>a script wants to authenticate without using cached
+            credentials.</para>
+          @ENGLISH }}} -->
+          <para>et skript vil identifisere seg uten å bruke lagrede 
+            brukerdata.</para>
+        </listitem>
+      </itemizedlist>
+
+
+      <!-- @ENGLISH {{{
+      <para>Here is a final summary that describes how a Subversion
+        client behaves when it receives an authentication
+        challenge:</para>
+      @ENGLISH }}} -->
+      <para>Her er en avsluttende oversikt som beskriver hvordan en 
+        Subversionklient oppfører seg når den mottar en 
+        autentiseringsforespørsel:</para>
+
+      <orderedlist>
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>Check whether the user specified any credentials as
+            command-line options, via <option>-ﳢ-username</option>
+            and/or <option>-ﳢ-password</option>.  If not, or if these
+            options fail to authenticate successfully, then</para>
+          @ENGLISH }}} -->
+          <para>Sjekk om brukeren spesifiserte noen brukerdata som 
+            kommandolinjevalg med <option>--username</option> og/eller 
+            <option>--password</option>.
+            Hvis ikke, eller hvis disse valgene ikke er i stand til å 
+            fullføre autentiseringen,</para>
+        </listitem>
+
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>Look up the server's realm in the runtime
+            <filename>auth/</filename> area, to see if the user already
+            has the appropriate credentials cached.  If not, or if the
+            cached credentials fail to authenticate, then</para>
+          @ENGLISH }}} -->
+          <para>Let opp &the_server;s område i 
+            <filename>auth/</filename>-området for å se om brukeren 
+            allerede har lagret de nødvendige identifikasjonsdataene.
+            Hvis ikke, eller hvis de lagrede brukerdataene ikke er 
+            tilstrekkelig for å autentisere,</para>
+        </listitem>
+
+        <listitem>
+          <!-- @ENGLISH {{{
+          <para>Resort to prompting the user.</para>
+          @ENGLISH }}} -->
+          <para>Spør brukeren.</para>
+        </listitem>
+      </orderedlist>
+
+      <!-- @ENGLISH {{{
+      <para>If the client successfully authenticates by any of the
+        methods listed above, it will attempt to cache the credentials
+        on disk (unless the user has disabled this behavior, as
+        mentioned earlier).</para>
+      @ENGLISH }}} -->
+      <para>Hvis klienten klarer å legitimere seg ved hjelp av noen av 
+        metodene nevnt ovenfor, vil den prøve å lagre brukerdataene på 
+        disken (unntatt hvis brukeren har slått av denne oppførselen, 
+        som tidligere nevnt).</para>
+
+    </sect2>
+
+  </sect1>
+
 </chapter>
 
 <!--

Modified: trunk/src/nb/book/ch-branching-and-merging.xml
==============================================================================
--- trunk/src/nb/book/ch-branching-and-merging.xml	(original)
+++ trunk/src/nb/book/ch-branching-and-merging.xml	Thu Jul 17 03:04:42 2008
@@ -132,13 +132,13 @@
       arbeid.</para>
 
   </sect1>
-  
+
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <sect1 id="svn.branchmerge.using">
     <!-- @ENGLISH {{{
-    <title>Using Branches</title> 
+    <title>Using Branches</title>
     @ENGLISH }}} -->
     <title>Bruke forgreninger</title> 
 
@@ -174,7 +174,7 @@
       inneholder hver prosjektkatalog underkataloger kalt 
       <filename>trunk</filename> og <filename>branches</filename>.
       Grunnen til dette vil du snart få greie på.</para>
-    
+
       <figure id="svn.branchmerge.using.dia-1">
         <!-- @ENGLISH {{{
         <title>Starting repository layout</title>
@@ -295,10 +295,10 @@
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.using.create">
     <!-- @ENGLISH {{{
-      <title>Creating a Branch</title> 
+      <title>Creating a Branch</title>
     @ENGLISH }}} -->
     <title>Opprette en forgrening</title>
-      
+
       <!-- @ENGLISH {{{
       <para>Creating a branch is very simple—you make a copy of
         the project in the repository using the <command>svn
@@ -457,7 +457,7 @@
         <filename>/calc/trunk</filename>.  This is shown in <xref
         linkend="svn.branchmerge.using.create.dia-1"/>.  Notice that the second method,
         however, performs an <emphasis>immediate</emphasis> commit.
-        <footnote> 
+        <footnote>
           <para>Subversion does not support
             cross-repository copying.  When using URLs with <command>svn
             copy</command> or <command>svn move</command>, you can only
@@ -485,7 +485,7 @@
         hente ut et stort speil av depotet.
         Faktisk trenger du med denne teknikken ikke en arbeidskopi i det 
         hele tatt.</para>
-      
+
       <figure id="svn.branchmerge.using.create.dia-1">
         <!-- @ENGLISH {{{
         <title>Repository with new copy</title>
@@ -493,13 +493,13 @@
         <title>Depot med ny kopi</title>
         <graphic fileref="images/ch04dia3.png"/>
       </figure>
-      
+
       <sidebar>
         <!-- @ENGLISH {{{
         <title>Cheap Copies</title>
         @ENGLISH }}} -->
         <title>Billige kopier</title>
-                
+
         <!-- @ENGLISH {{{
         <para>Subversion's repository has a special design.  When you
           copy a directory, you don't need to worry about the
@@ -527,7 +527,7 @@
           den kopierte katalogen, forandrer bare denne fila seg – resten 
           av filene fortsetter å eksistere som lenker til de originale 
           filene i den originale katalogen.</para>
-      
+
         <!-- @ENGLISH {{{
         <para>This is why you'll often hear Subversion users talk
           about <quote>cheap copies</quote>.  It doesn't matter how
@@ -568,7 +568,7 @@
       </sidebar>
 
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.using.work">
       <!-- @ENGLISH {{{
@@ -978,7 +978,7 @@
       hull</quote>-strategien er at når du er ferdig med grenen din, vil 
       det bli nesten umulig å flette inn dine forandringer tilbake til 
       <filename>trunk</filename> uten et stort antall konflikter.</para>
-    
+
     <!-- @ENGLISH {{{
     <para>Instead, you and Sally might continue to share changes as
       you work.  It's up to you to decide which changes are worth
@@ -995,7 +995,7 @@
       Og når du er fullstendig ferdig med din gren, kan hele settet med 
       grenforandringer bli kopiert tilbake til 
       <filename>trunk</filename>.</para>
-    
+
 
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.specific">
@@ -1003,7 +1003,7 @@
       <title>Copying Specific Changes</title>
       @ENGLISH }}} -->
       <title>Kopiere spesifikke forandringer</title>
-      
+
 
       <!-- @ENGLISH {{{
       <para>In the previous section, we mentioned that both you and
@@ -1076,25 +1076,25 @@
      high = high << 8;  /* interpret MSB correctly */
 -    total = low + high; /* add them togethe for correct total */
 +    total = low + high; /* add them together for correct total */
- 
+
      info->extra_header = (unsigned char *) my_malloc(total);
      fread(info->extra_header, total, 1, gzfile);
 @@ -241,7 +241,7 @@
       Store the offset with ftell() ! */
- 
+
    if ((info->data_offset = ftell(gzfile))== -1) {
 -    printf("error: ftell() retturned -1.\n");
 +    printf("error: ftell() returned -1.\n");
      exit(1);
    }
- 
+
 @@ -249,7 +249,7 @@
    printf("I believe start of compressed data is %u\n", info->data_offset);
    #endif
-   
+
 -  /* Set postion eight bytes from the end of the file. */
 +  /* Set position eight bytes from the end of the file. */
- 
+
    if (fseek(gzfile, -8, SEEK_END)) {
      printf("error: fseek() returned non-zero\n");
 </screen>
@@ -1143,7 +1143,7 @@
    if (fseek(gzfile, -8, SEEK_END)) {
      printf("error: fseek() returned non-zero\n");
 </screen>
-      
+
       <!-- @ENGLISH {{{
       <para>The <command>svn merge</command> command is almost exactly
         the same.  Instead of printing the differences to your
@@ -1155,7 +1155,7 @@
         Istedenfor å skrive forskjellene til terminalen din, blir de 
         lagt direkte til arbeidskopien din som <emphasis>lokale 
         modifikasjoner</emphasis>:</para>
-    
+
       <screen>
 $ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk
 U  integer.c
@@ -1347,7 +1347,7 @@
           direkte inn i arbeidskopien din.</para>
 
       </sidebar>
-      
+
       <!-- @ENGLISH {{{
       <para>A word of warning: while <command>svn diff</command> and
         <command>svn merge</command> are very similar in concept, they
@@ -1410,7 +1410,7 @@
         <command>svn merge</command> ut i fra det andre tilfellet og 
         forsøker å legge inn forandringene til en lokal fil med det 
         samme navnet.</para>
-      
+
       <!-- @ENGLISH {{{
       <para>If you want changes applied somewhere else, you'll
         need to say so.  For example, if you're sitting in the parent
@@ -1422,7 +1422,7 @@
         Hvis du for eksempel sitter i foreldrekatalogen til 
         arbeidskopien din, må du spesifisere målkatalogen som skal motta 
         forandringene:</para>
-      
+
       <screen>
 $ svn merge -r 343:344 http://svn.example.com/repos/calc/trunk my-calc-branch
 U   my-calc-branch/integer.c
@@ -1522,7 +1522,7 @@
             forandringer (ofte kalt <firstterm>målet</firstterm> til 
             flettingen).</para>
         </listitem>
-        
+
       </orderedlist>
 
       <!-- @ENGLISH {{{
@@ -1556,11 +1556,11 @@
         Her er noen eksempler:</para>
 
       <!-- @ENGLISH {{{
-      <screen>      
+      <screen>
 $ svn merge http://svn.example.com/repos/branch1@150 \
             http://svn.example.com/repos/branch2@212 \
             my-working-copy
-            
+
 $ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
 
 $ svn merge -r 100:200 http://svn.example.com/repos/trunk
@@ -1597,7 +1597,7 @@
 
 
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.copychanges.bestprac">
       <!-- @ENGLISH {{{
@@ -1701,13 +1701,13 @@
           teknikken i praksis.</para>
 
       </sect3>
-      
+
       <sect3 id="svn.branchmerge.copychanges.bestprac.preview">
         <!-- @ENGLISH {{{
         <title>Previewing Merges</title>
         @ENGLISH }}} -->
         <title>Vise flettinger på forhånd</title>
-        
+
         <!-- @ENGLISH {{{
         <para>Because merging only results in local modifications,
           it's not usually a high-risk operation.  If you get the
@@ -1719,7 +1719,7 @@
           Hvis flettingen går galt første gangen, kan du kjøre 
           <command>svn revert</command> på forandringene og prøve 
           igjen.</para>
-        
+
         <!-- @ENGLISH {{{
         <para>It's possible, however, that your working copy might
           already have local modifications.  The changes applied by a
@@ -1985,7 +1985,7 @@
           fletting.</para>
 
       </sect3>
-      
+
       <sect3 id="svn.branchmerge.copychanges.bestprac.ancestry">
         <!-- @ENGLISH {{{
         <title>Noticing or Ignoring Ancestry</title>
@@ -2293,7 +2293,7 @@
 
 $
 </screen>
-        
+
         <!-- @ENGLISH {{{
         <para>As expected, the final revision printed by this command
           is the revision in which <filename>my-calc-branch</filename>
@@ -2432,7 +2432,7 @@
 ------------------------------------------------------------------------
 …
 </screen>
-      
+
       <!-- @ENGLISH {{{
       <para>Aha!  Since all branch-changes that happened between
         revisions 341 and 405 were previously merged to the trunk as
@@ -2595,7 +2595,7 @@
         I vårt tilfelle med å omgjøre en forandring ber vi <command>svn 
         merge</command> om å legge inn forandringssett nummer 303 
         <emphasis>baklengs</emphasis> inn i arbeidskopien vår.</para>
-    
+
       <sidebar>
         <!-- @ENGLISH {{{
         <title>Subversion and Changesets</title>
@@ -2898,15 +2898,16 @@
       <para>Dette var den vanskelige delen – <!-- ¤ -->etterforskningen.
         Nå som du vet hva du vil hente tilbake, har du to forskjellige 
         valg.</para>
-      
+
       <!-- @ENGLISH {{{
       <para>One option is to use <command>svn merge</command> to apply
         revision 808 <quote>in reverse</quote>.  (We've already
-        discussed how to undo changes, see <xref
-        linkend="svn.branchmerge.commonuses.undo"/>.)  This would have the effect of
-        re-adding <filename>real.c</filename> as a local modification.
-        The file would be scheduled for addition, and after a commit,
-        the file would again exist in <literal>HEAD</literal>.</para>
+        discussed how to undo changes, see
+        <xref linkend="svn.branchmerge.commonuses.undo"/>.)  This
+        would have the effect of re-adding <filename>real.c</filename>
+        as a local modification.  The file would be scheduled for
+        addition, and after a commit, the file would again exist
+        in <literal>HEAD</literal>.</para>
       @ENGLISH }}} -->
       <para>En måte er å bruke <command>svn merge</command> for å legge 
         inn revisjon 808 <quote>i revers</quote>.
@@ -3051,13 +3052,13 @@
         de kan brukes med ethvert versjonskontrollsystem.
         Men det kan hjelpe å se dem beskrevet i 
         Subversionterminologi.</para>
-      
+
       <sect3 id="svn.branchmerge.commonuses.patterns.release">
         <!-- @ENGLISH {{{
         <title>Release Branches</title>
         @ENGLISH }}} -->
         <title>Utgivelsesgrener</title>
-      
+
         <!-- @ENGLISH {{{
         <para>Most software has a typical lifecycle: code, test,
           release, repeat.  There are two problems with this process.
@@ -3153,7 +3154,7 @@
             Grenen er <quote>frosset</quote> for avsluttende testing 
             rett før en utgivelse.</para>
         </listitem>
-          
+
         <listitem>
           <!-- @ENGLISH {{{
           <para><emphasis>The branch is tagged and released.</emphasis>
@@ -3222,7 +3223,7 @@
         <title>Feature Branches</title>
         @ENGLISH }}} -->
         <title>Funksjonalitetsgrener</title>
-      
+
         <!-- @ENGLISH {{{
         <para>A <firstterm>feature branch</firstterm> is the sort of
           branch that's been the dominant example in this chapter, the
@@ -3338,10 +3339,13 @@
           merge the last week's worth of trunk changes to the branch.
           Take care when doing this; the merging needs to be
           hand-tracked to avoid the problem of repeated merges (as
-          described in <xref linkend="svn.branchmerge.copychanges.bestprac.track"/>).  You'll
-          need to write careful log messages detailing exactly which
-          revision ranges have been merged already (as
-          demonstrated in <xref linkend="svn.branchmerge.commonuses.wholebr"/>).  It
+          described in
+          <xref
+          linkend="svn.branchmerge.copychanges.bestprac.track"/>).
+          You'll need to write careful log messages detailing exactly
+          which revision ranges have been merged already (as
+          demonstrated in
+          <xref linkend="svn.branchmerge.commonuses.wholebr"/>).  It
           may sound intimidating, but it's actually pretty easy to
           do.</para>
         @ENGLISH }}} -->
@@ -3572,7 +3576,7 @@
             trunk-arbeidskopien for å avspeile forgreningen.</para>
         </listitem>
       </orderedlist>
-    
+
     <!-- @ENGLISH {{{
     <para>In other words, if a user knows that the branch-work only
       needs to happen on a specific subdirectory, they use
@@ -3601,7 +3605,7 @@
       konseptet med en <quote>blandet arbeidskopi</quote> – ikke bare 
       kan arbeidskopier inneholde en blanding av av arbeidsrevisjoner, 
       men også en blanding av depotbeliggenheter.</para>
-    
+
     <!-- @ENGLISH {{{
     <para>If your working copy contains a number of switched subtrees
       from different repository locations, it continues to function as
@@ -3646,13 +3650,13 @@
           Se <command>svn switch</command>-seksjonen i <xref 
           linkend="svn.ref"/> for mer informasjon og et eksempel.</para>
       </footnote></para>
-    
+
     <sidebar>
       <!-- @ENGLISH {{{
       <title>Switches and Updates</title>
       @ENGLISH }}} -->
       <title>Ombyttinger og oppdateringer</title>
-      
+
       <!-- @ENGLISH {{{
       <para>Have you noticed that the output of <command>svn
         switch</command> and <command>svn update</command> look the
@@ -3686,7 +3690,7 @@
         <command>svn update</command> er at 
         <literal>update</literal>-kommandoen alltid sammenligner to 
         identiske stier.</para>
-      
+
       <!-- @ENGLISH {{{
       <para>That is, if your working copy is a mirror of
         <filename>/calc/trunk</filename>, then <command>svn
@@ -3932,14 +3936,14 @@
         Dette er versjonskontroll, tross alt.</para>
 
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.tags.mkcomplex">
       <!-- @ENGLISH {{{
       <title>Creating a Complex Tag</title>
       @ENGLISH }}} -->
       <title>Lage et komplekst merke</title>
-      
+
       <!-- @ENGLISH {{{
       <para>Sometimes you may want your <quote>snapshot</quote> to be
         more complicated than a single directory at a single
@@ -3948,7 +3952,7 @@
       <para>Noen ganger vil du at <quote>øyeblikksbildet</quote> skal 
         være mer komplisert enn en enkel katalog med en enkelt 
         revisjon.</para>
-      
+
       <!-- @ENGLISH {{{
       <para>For example, pretend your project is much larger than our
         <filename>calc</filename> example: suppose it contains a
@@ -4093,7 +4097,7 @@
       <title>Repository Layout</title>
       @ENGLISH }}} -->
       <title>Utseendet på depotet</title>
-      
+
       <!-- @ENGLISH {{{
       <para>There are some standard, recommended ways to organize a
         repository.  Most people create a <filename>trunk</filename>
@@ -4190,9 +4194,9 @@
         som ikke lenger finnes, og brukeren vil bli tvunget til å bruke 
         <command>svn switch</command> for å sette arbeidskopien til den 
         nye plasseringen.</para>
-      
+
     </sect2>
-    
+
     <!-- =============================================================== -->
     <sect2 id="svn.branchmerge.maint.lifetime">
       <!-- @ENGLISH {{{
@@ -4393,7 +4397,7 @@
       Denne situasjonen oppstår hele tiden – alle steder der 
       informasjonen generert av en gruppe har en direkte effekt på hva 
       som er generert av en annen gruppe.</para>
- 
+
     <!-- @ENGLISH {{{
     <para>For example, software developers might be working on an
       application which makes use of a third-party library.
@@ -4616,7 +4620,7 @@
              -m 'Importerer innledende 1.0-versjon'
 …
 </screen>
-    
+
       <!-- @ENGLISH {{{
       <para>We now have the current version of the libcomplex source
         code in <filename>/vendor/libcomplex/current</filename>.  Now,
@@ -4638,7 +4642,7 @@
         prosjektkatalogen <filename>calc</filename>.
         Det er i denne kopien av leverandørdataene vi vil gjøre 
         forandringene.</para>
-    
+
       <!-- @ENGLISH {{{
       <screen>
 $ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
@@ -4707,7 +4711,7 @@
         Men vi gjør det faktisk den andre veien, legger inn 
         forandringene i libcomplex mellom versjon 1.0 og 1.1 i den 
         modifiserte kopien av den.</para>
-      
+
       <!-- @ENGLISH {{{
       <para>To perform this upgrade, we checkout a copy of our vendor
         branch, and replace the code in the
@@ -5033,7 +5037,7 @@
 </chapter>
 
 <!--
-local variables: 
+local variables:
 sgml-parent-document: ("book.xml" "chapter")
 end:
 vim: set ft=svnbook :

Modified: trunk/src/nb/book/ch-customizing-svn.xml
==============================================================================
--- trunk/src/nb/book/ch-customizing-svn.xml	(original)
+++ trunk/src/nb/book/ch-customizing-svn.xml	Thu Jul 17 03:04:42 2008
@@ -4,7 +4,7 @@
   @ENGLISH }}} -->
 <!-- @CHK {{ -->
   <!-- ¤ -->
-  <title>Tilpassing av Subversion-opplevelsen</title>
+  <title>Tilpasse Subversion til din smak</title>
 
   <para>### TODO: Chapter opening ###</para>
 
@@ -378,7 +378,8 @@
 "#ssl-client-cert-password"=""
 
 [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auth]
-"#store-auth-creds"="no"
+"#store-passwords"="yes"
+"#store-auth-creds"="yes"
 
 [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\helpers]
 "#editor-cmd"="notepad"
@@ -386,16 +387,17 @@
 "#diff3-cmd"=""
 "#diff3-has-program-arg"=""
 
+[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\tunnels]
+
 [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\miscellany]
 "#global-ignores"="*.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store"
 "#log-encoding"=""
 "#use-commit-times"=""
-"#template-root"=""
+"#no-unlock"=""
 "#enable-auto-props"=""
 
-[HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\tunnels]
-
 [HKEY_CURRENT_USER\Software\Tigris.org\Subversion\Config\auto-props]
+
 </programlisting>
       </example>
 
@@ -791,7 +793,7 @@
                 the <option>-ﳢ-no-auth-cache</option> command-line
                 parameter (for those subcommands that support it).
                 For more information, see <xref
-                linkend="svn.serverconfig.netmodel.credcache"/>.</para>
+                linkend="svn.advanced.netmodel.credcache"/>.</para>
               @ENGLISH }}} -->
               <para>Dette ber Subversion om å lagre, eller ikke lagre, 
                 passord som blir skrevet av brukeren som respons til 
@@ -804,7 +806,7 @@
                 kommanolinjevalget <option>--no-auth-cache</option> 
                 sammen med de delkommandoene som støtter det.
                 For mer informasjon, se <xref 
-                linkend="svn.serverconfig.netmodel.credcache"/>.</para>
+                linkend="svn.advanced.netmodel.credcache"/>.</para>
             </listitem>
           </varlistentry>
           <varlistentry>

Modified: trunk/src/nb/book/ch-server-configuration.xml
==============================================================================
--- trunk/src/nb/book/ch-server-configuration.xml	(original)
+++ trunk/src/nb/book/ch-server-configuration.xml	Thu Jul 17 03:04:42 2008
@@ -512,523 +512,6 @@
   <!-- ================================================================= -->
   <!-- ================================================================= -->
   <!-- ================================================================= -->
-  <sect1 id="svn.serverconfig.netmodel">
-
-    <!-- @ENGLISH {{{
-    <title>Network Model</title>
-    @ENGLISH }}} -->
-    <title>Nettverksmodellen</title>
-
-    <!-- @ENGLISH {{{
-    <para>This section is a general discussion of how a Subversion
-      client and server interact with one another, regardless of the
-      network implementation you're using.  After reading, you'll have
-      a good understanding of how a server can behave and the
-      different ways in which a client can be configured to
-      respond.</para>
-    @ENGLISH }}} -->
-    <para>Denne seksjonen er en generell diskusjon om hvordan en 
-      Subversionklient og -&server; kommuniserer med hverandre, 
-      uavhengig av hvilken nettverksimplementasjon du bruker.
-      Etter å ha lest dette vil du ha en god forståelse av hvordan en 
-      &server; kan oppføre seg og de forskjellige måtene en klient kan 
-      settes opp til å svare.</para>
-
-    <!-- =============================================================== -->
-    <sect2 id="svn.serverconfig.netmodel.reqresp">
-      <!-- @ENGLISH {{{
-      <title>Requests and Responses</title>
-      @ENGLISH }}} -->
-      <title>Forespørsler og reponser</title>
-
-      <!-- @ENGLISH {{{
-      <para>The Subversion client spends most of its time managing
-        working copies.  When it needs information from a repository,
-        however, it makes a network request, and the server responds
-        with an appropriate answer.  The details of the network
-        protocol are hidden from the user; the client attempts to
-        access a URL, and depending on the URL schema, a particular
-        protocol is used to contact the server (see <xref
-        linkend="svn.basic.in-action.wc.sb-1"/>).  Users can run <command>svn
-        -ﳢ-version</command> to see which URL schemas and protocols the
-        client knows how to use.</para>
-      @ENGLISH }}} -->
-      <para>Subversionklienten bruker mesteparten av tida til å behandle 
-        arbeidskopier.
-        Men når den trenger informasjon fra et depot foretar den en 
-        nettverksforespørsel og &the_server; kommer med et passende 
-        svar.
-        Detaljene i nettverksprotokollen er skjult for brukeren; 
-        klienten prøver å aksessere en URL, og alt etter hvilket 
-        URL-skjema som brukes blir en passende protokoll brukt for å 
-        aksessere &the_server; (se <xref 
-        linkend="svn.basic.in-action.wc.sb-1"/>).
-        Brukere kan kjøre <command>svn --version</command> for å se 
-        hvilke URL-skjema og protokoller klienten kan bruke.</para>
-
-      <!-- @ENGLISH {{{
-      <para>When the server process receives a client request, it
-        typically demands that the client identify itself.  It issues
-        an authentication challenge to the client, and the client
-        responds by providing <firstterm>credentials</firstterm> back
-        to the server.  Once authentication is complete, the server
-        responds with the original information the client asked for.
-        Notice that this system is different from systems like CVS,
-        where the client pre-emptively offers credentials (<quote>logs
-        in</quote>) to the server before ever making a request.  In
-        Subversion, the server <quote>pulls</quote> credentials by
-        challenging the client at the appropriate moment, rather than
-        the client <quote>pushing</quote> them.  This makes certain
-        operations more elegant.  For example, if a server is
-        configured to allow anyone in the world to read a repository,
-        then the server will never issue an authentication challenge
-        when a client attempts to <command>svn
-        checkout</command>.</para>
-      @ENGLISH }}} -->
-      <para>Når &the_server; mottar en klientforespørsel, forlanger den 
-        vanligvis at klienten identifiserer seg.
-        Den utsteder en autentiseringsforespørsel til klienten, og 
-        klienten svarer ved å <firstterm>legitimere</firstterm> seg 
-        ovenfor &the_server;.
-        Når autentiseringen er komplett, svarer &the_server; med den 
-        originale informasjonen klienten spurte etter.
-        Legg merke til at dette systemet er forskjellig fra systemer som 
-        CVS, hvor klienten på forhånd oppgir legitimasjon (<quote>logger 
-        inn</quote>) til &the_server; før noen forespørsel etter 
-        informasjon blir gjort.
-        I Subversion <quote>henter</quote> &the_server; legitimasjonen 
-        ved å kontrollere klienten på det nødvendige tidspunktet i 
-        stedet for at klienten uoppfordret <quote>leverer</quote> den.
-        Dette gjør visse operasjoner mer elegant.
-        For eksempel, hvis en &server; er konfigurert til å la alle i 
-        hele verden få lese depotet, vil &the_server; aldri be om 
-        autentisering når klienten prøver en <command>svn 
-        checkout</command>.</para>
-
-      <!-- @ENGLISH {{{
-      <para>If the client's network request writes new data to the
-        repository (e.g. <command>svn commit</command>), then a new
-        revision tree is created.  If the client's request was
-        authenticated, then the authenticated user's name is stored as
-        the value of the <literal>svn:author</literal> property on the
-        new revision (see <xref linkend="svn.reposadmin.basics.revprops"/>).  If
-        the client was not authenticated (in other words, the server
-        never issued an authentication challenge), then the revision's
-        <literal>svn:author</literal> property is empty.
-        <footnote><para>This problem is actually a FAQ, resulting from
-        a misconfigured server setup.</para></footnote></para>
-      @ENGLISH }}} -->
-      <para>Hvis klientens nettverksforespørsel skriver nye data til 
-        depotet (for eksempel <command>svn commit</command>), vil et 
-        nytt revisjonstre bli opprettet.
-        Hvis klientens forespøsel ble autentisert, blir brukernavnet til 
-        den autentiserte brukeren lagret i 
-        <literal>svn:author</literal>-egenskapen i den nye revisjonen 
-        (se <xref linkend="svn.reposadmin.basics.revprops"/>).
-        Hvis klienten ikke ble autentisert (med andre ord, &the_server; 
-        spurte ikke etter legitimasjon), er revisjonens 
-        <literal>svn:author</literal>-egenskap tom.<footnote>
-          <para>Dette er egentlig et spørsmål som ofte dukker opp som et 
-            resultat av feil i konfigurasjonen på &the_server;.</para>
-        </footnote></para>
-
-    </sect2>
-
-    <!-- =============================================================== -->
-    <sect2 id="svn.serverconfig.netmodel.credcache">
-      <!-- @ENGLISH {{{
-      <title>Client Credentials Caching</title>
-      @ENGLISH }}} -->
-      <title>Lagring av klientlegitimasjon</title>
-
-      <!-- @ENGLISH {{{
-      <para>Many servers are configured to require authentication on
-        every request.  This can become a big annoyance to users, who
-        are forced to type their passwords over and over again.</para>
-      @ENGLISH }}} -->
-      <para>Mange &servers; er satt opp til å forlange autentisering for 
-        hver eneste forespørsel.
-        Dette kan bli et stort irritasjonsmoment for brukerne, som blir 
-        tvunget til å skrive passordet om og om igjen.</para>
-
-      <!-- @ENGLISH {{{
-      <para>Happily, the Subversion client has a remedy for this: a
-        built-in system for caching authentication credentials on
-        disk.  By default, whenever the command-line client
-        successfully responds to a server's authentication challenge,
-        it saves the credentials in the user's private runtime
-        configuration
-        area—in <filename>~/.subversion/auth/</filename> on
-        Unix-like systems or
-        <filename>%APPDATA%/Subversion/auth/</filename> on Windows.
-        (The runtime area is covered in more detail in <xref
-        linkend="svn.advanced.confarea"/>.)  Successful credentials are
-        cached on disk, keyed on a combination of hostname, port, and
-        authentication realm.</para>
-      @ENGLISH }}} -->
-      <para>Heldigvis har Subversion en løsning på dette:
-        Et innebygget system for å lagre legitimasjonen på disk.
-        Normalt sett, når kommandolinjeklienten klarer å svare riktig på 
-        en autentiseringsforespørsel fra en &server;, lagres denne 
-        legitimasjonsinformasjonen i brukerens private <!-- ¤ runtime 
-        -->konfigurasjonsområde – i 
-        <filename>~/.subversion/auth/</filename> på Unix-lignende 
-        systemer eller <filename>%APPDATA%/Subversion/auth/</filename> i 
-        Windows.
-        (<!-- ¤ runtime igjen – fellesordlista til Skolelinux oversetter 
-        dette med «kjøretid», men … vel. I dette tilfellet passer det 
-        vel bedre å ikke ha det med. -->Konfigurasjonsområdet er dekket 
-        mer inngående i <xref linkend="svn.advanced.confarea"/>.)
-        Data fra vellykkede autentiseringer lagres på disken, der 
-        nøkkelen er en kombinasjon av &server;navn, port og området der 
-        autentiseringen gjelder.</para>
-
-      <!-- @ENGLISH {{{
-      <para>When the client receives an authentication challenge, it
-        first looks for the appropriate credentials in the user's disk
-        cache; if not present, or if the cached credentials fail to
-        authenticate, then the client simply prompts the user for the
-        information.</para>
-      @ENGLISH }}} -->
-      <para>Når klienten må gjennom en autentiseringsprosess, ser den 
-        først etter passende legitimasjonsdata i brukerens lager på 
-        disken.
-        Hvis dette ikke finnes, eller de lagrede legitimasjonsdataene 
-        ikke er tilstrekkelig for å fullføre autentiseringen, spør 
-        klienten ganske enkelt brukeren etter informasjonen.</para>
-
-      <!-- @ENGLISH {{{
-      <para>Security-conscious people may be thinking to themselves,
-        <quote>Caching passwords on disk?  That's terrible!  You
-        should never do that!</quote> Please remain calm, it's not as
-        dangerous as it sounds.</para>
-      @ENGLISH }}} -->
-      <para>Sikkerhetsbevisste folk tenker nok med seg selv:
-        <quote>Lagre passord på disken?
-        Det er forferdelig!
-        Sånt skal aldri gjøres!</quote>
-        Men ta det med ro, det er ikke så farlig som det høres 
-        ut.</para>
-
-      <itemizedlist>
-
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>On Windows 2000 and later, the Subversion client uses
-            standard Windows cryptography services to encrypt the
-            password on disk.  Because the encryption key is managed
-            by Windows and is tied to the user's own login
-            credentials, only the user can decrypt the cached
-            password.  (Note: if the user's Windows account password
-            is reset by an administrator, all of the cached passwords
-            become undecipherable.  The Subversion client will behave
-            as if they don't exist, prompting for passwords when
-            required.)</para>
-          @ENGLISH }}} -->
-          <para>På Windows 2000 og senere bruker Subversionklienten 
-            standard kryptografitjenester i Windows for å kryptere 
-            passordet på disken.
-            Fordi krypteringsnøkkelen blir vedlikeholdt av Windows og 
-            den er forbundet med brukerens egne <!-- ¤ credentials 
-            -->innloggingsbrukerdata, kan bare brukeren dekryptere det 
-            lagrede passordet.
-            (Merk:
-            Hvis brukerens passord i Windows blir resatt av en 
-            administrator, kan ikke de lagrede passordene dekrypteres.
-            Subversionklienten vil oppføre seg som om de ikke eksisterer 
-            og spørre etter passord når det er nødvendig.)</para>
-        </listitem>
-
-<!-- @TR {{ -->
-        <listitem>
-          <para>Similarly, on Mac OS X, the Subversion client stores all
-            repository passwords in the Keychain service, protected by
-            the user's account passsword.</para>
-        </listitem>
-<!-- @TR }} -->
-
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>For other Unix-like operating systems, no standard
-            such <quote>keychain</quote> services exist.  However,
-            the <filename>auth/</filename> caching area is still
-            permission-protected so that only the user (owner) can
-            read data from it, not the world at large.  The operating
-            system's own file permissions are protecting the
-            password.</para>
-          @ENGLISH }}} -->
-          <para>For andre Unix-lignende operativsystemer eksisterer det 
-            ingen slike standardiserte 
-            <quote>nøkkelring</quote>-tjenester.
-            Imidlertid er lagringsområdet i <filename>auth/</filename> 
-            fortsatt beskyttet av rettigheter så bare brukeren (eieren) 
-            kan lese dataene derfra, ikke resten av verden.
-            Operativsystemets egne filrettigheter beskytter 
-            passordet.</para>
-        </listitem>
-
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>For the truly paranoid willing to sacrifice
-            convenience, it's always possible to disable credential
-            caching altogether.</para>
-          @ENGLISH }}} -->
-          <para>For den sanne paranoide som er villig til å ofre 
-            behageligheter, er det alltids mulig å deaktivere all 
-            lagring av legitimasjonsdata.</para>
-        </listitem>
-
-      </itemizedlist>
-
-      <!-- @ENGLISH {{{
-      <para>To disable caching for a single command, pass the
-        <option>-ﳢ-no-auth-cache</option> option:</para>
-      @ENGLISH }}} -->
-      <para>For å forhindre lagring for en enkelt kommando, spesifiser 
-        valget <option>--no-auth-cache</option>:</para>
-
-      <!-- @ENGLISH {{{
-      <screen>
-$ svn commit -F log_msg.txt -ﳢ-no-auth-cache
-Authentication realm: <svn://host.example.com:3690> example realm
-Username:  joe
-Password for 'joe':
-
-Adding         newfile
-Transmitting file data .
-Committed revision 2324.
-
-# password was not cached, so a second commit still prompts us
-
-$ svn delete newfile
-$ svn commit -F new_msg.txt
-Authentication realm: <svn://host.example.com:3690> example realm
-Username:  joe
-…
-</screen>
-      @ENGLISH }}} -->
-<!-- @TR {{ -->
-      <screen>
-$ svn commit -F log_msg.txt --no-auth-cache
-Authentication realm: <svn://host.example.com:3690> example realm
-Username:  joe
-Password for 'joe':
-
-Adding         newfile
-Transmitting file data .
-Committed revision 2324.
-
-# Passordet ble ikke lagret, så ved neste innlegging blir vi spurt på 
-# nytt.
-
-$ svn delete newfile
-$ svn commit -F new_msg.txt
-Authentication realm: <svn://host.example.com:3690> example realm
-Username:  joe
-…
-</screen>
-<!-- @TR }} -->
-
-      <!-- @ENGLISH {{{
-      <para>Or, if you want to disable credential caching permanently,
-        you can edit your runtime <filename>config</filename> file
-        (located next to the <filename>auth/</filename> directory).
-        Simply set <literal>store-auth-creds</literal> to
-        <literal>no</literal>, and no credentials will be cached on
-        disk, ever.</para>
-      @ENGLISH }}} -->
-      <para>Eller, hvis du vil slå av lagring av legitimasjonen 
-        permanent, kan du redigere <filename>config</filename>-fila 
-        (plassert ved siden av <filename>auth/</filename>-katalogen).
-        Ved å sette <literal>store-auth-creds</literal> til 
-        <literal>no</literal> vil ingen legitimasjon bli lagret på 
-        disken i det hele tatt.</para>
-
-      <screen>
-[auth]
-store-auth-creds = no
-</screen>
-
-      <!-- @ENGLISH {{{
-      <para>Sometimes users will want to remove specific credentials
-        from the disk cache.  To do this, you need to navigate into
-        the <filename>auth/</filename> area and manually delete the
-        appropriate cache file.  Credentials are cached in individual
-        files;  if you look inside each file, you will see keys and
-        values.  The <literal>svn:realmstring</literal> key describes
-        the particular server realm that the file is associated
-        with:</para>
-      @ENGLISH }}} -->
-      <para>Noen ganger vil brukere ønske å fjerne spesifikke 
-        legitimasjonsdata fra disklageret.
-        For å gjøre dette, må du gå inn i 
-        <filename>auth/</filename>-området og manuelt slette den 
-        aktuelle fila.
-        Legitimasjonen er lagret i individuelle filer, og hvis du ser på 
-        hver fil, vil du se nøkler og verdier.
-        <literal>svn:realmstring</literal>-nøkkelen viser hvilket 
-        &server;område fila er assosiert med:</para>
-
-      <screen>
-$ ls ~/.subversion/auth/svn.simple/
-5671adf2865e267db74f09ba6f872c28
-3893ed123b39500bca8a0b382839198e
-5c3c22968347b390f349ff340196ed39
-
-$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28
-
-K 8
-username
-V 3
-joe
-K 8
-password
-V 4
-blah
-K 15
-svn:realmstring
-V 45
-<https://svn.domain.com:443> Joe's repository
-END
-</screen>
-
-      <!-- @ENGLISH {{{
-      <para>Once you have located the proper cache file, just delete
-        it.</para>
-      @ENGLISH }}} -->
-      <para>Når du har funnet den riktige fila, er det bare å slette 
-        den.</para>
-
-      <!-- @ENGLISH {{{
-      <para>One last word about client authentication behavior: a bit
-        of explanation about the <option>-ﳢ-username</option> and
-        <option>-ﳢ-password</option> options is needed.  Many client
-        subcommands accept these options; however it is important to
-        understand using these options <emphasis>does not</emphasis>
-        automatically send credentials to the server.  As discussed
-        earlier, the server <quote>pulls</quote> credentials from the
-        client when it deems necessary; the client cannot
-        <quote>push</quote> them at will.  If a username and/or
-        password are passed as options, they will
-        <emphasis>only</emphasis> be presented to the server if the
-        server requests them.
-
-         <footnote><para>Again, a common mistake is to misconfigure a
-           server so that it never issues an authentication challenge.
-           When users pass <option>-ﳢ-username</option> and
-           <option>-ﳢ-password</option> options to the client,
-           they're surprised to see that they're never used, i.e. new
-           revisions still appear to have been committed
-           anonymously!</para></footnote>
-
-        Typically, these options are used when:</para>
-      @ENGLISH }}} -->
-      <para>Et siste ord om oppførselen under klientautentisering, en 
-        liten forklaring angående <option>--username</option> og 
-        <option>--password</option> er på sin plass.
-        Mange delkommandoer for klienten godtar disse valgene, men det 
-        er viktig å forstå at bruken av disse valgene sender 
-        <emphasis>ikke</emphasis> brukerdata til &the_server;.
-        Som tidligere nevnt, <quote>henter</quote> &the_server; 
-        brukerdata fra klienten når det er nødvendig; klienten kan ikke 
-        <quote>levere</quote> dataene når den vil.
-        Hvis et brukernavn og/eller passord blir spesifisert som valg, 
-        vil de <emphasis>bare</emphasis> bli gitt til &the_server; hvis 
-        &the_server; spør etter dem.<footnote>
-          <para>Som sagt, en vanlig feil er å feilkonfigurere 
-            &the_server; så den aldri spør etter autentiseringsinfo.
-            Når brukere angir <option>--username</option> og 
-            <option>--password</option> til klienten, blir de overrasket 
-            over å se at dataene aldri blir brukt og at nye revisjoner 
-            fortsatt ser ut til å ha blitt lagt inn anonymt!</para>
-        </footnote>
-        Vanligvis blir disse valgene brukt når:</para>
-
-      <itemizedlist>
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>the user wants to authenticate as a different user
-            than her system login name, or</para>
-          @ENGLISH }}} -->
-          <para>brukeren vil identifisere seg som en annen bruker enn 
-            brukernavnet på systemet, eller</para>
-        </listitem>
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>a script wants to authenticate without using cached
-            credentials.</para>
-          @ENGLISH }}} -->
-          <para>et skript vil identifisere seg uten å bruke lagrede 
-            brukerdata.</para>
-        </listitem>
-      </itemizedlist>
-
-
-      <!-- @ENGLISH {{{
-      <para>Here is a final summary that describes how a Subversion
-        client behaves when it receives an authentication
-        challenge:</para>
-      @ENGLISH }}} -->
-      <para>Her er en avsluttende oversikt som beskriver hvordan en 
-        Subversionklient oppfører seg når den mottar en 
-        autentiseringsforespørsel:</para>
-
-      <orderedlist>
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>Check whether the user specified any credentials as
-            command-line options, via <option>-ﳢ-username</option>
-            and/or <option>-ﳢ-password</option>.  If not, or if these
-            options fail to authenticate successfully, then</para>
-          @ENGLISH }}} -->
-          <para>Sjekk om brukeren spesifiserte noen brukerdata som 
-            kommandolinjevalg med <option>--username</option> og/eller 
-            <option>--password</option>.
-            Hvis ikke, eller hvis disse valgene ikke er i stand til å 
-            fullføre autentiseringen,</para>
-        </listitem>
-
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>Look up the server's realm in the runtime
-            <filename>auth/</filename> area, to see if the user already
-            has the appropriate credentials cached.  If not, or if the
-            cached credentials fail to authenticate, then</para>
-          @ENGLISH }}} -->
-          <para>Let opp &the_server;s område i 
-            <filename>auth/</filename>-området for å se om brukeren 
-            allerede har lagret de nødvendige identifikasjonsdataene.
-            Hvis ikke, eller hvis de lagrede brukerdataene ikke er 
-            tilstrekkelig for å autentisere,</para>
-        </listitem>
-
-        <listitem>
-          <!-- @ENGLISH {{{
-          <para>Resort to prompting the user.</para>
-          @ENGLISH }}} -->
-          <para>Spør brukeren.</para>
-        </listitem>
-      </orderedlist>
-
-      <!-- @ENGLISH {{{
-      <para>If the client successfully authenticates by any of the
-        methods listed above, it will attempt to cache the credentials
-        on disk (unless the user has disabled this behavior, as
-        mentioned earlier).</para>
-      @ENGLISH }}} -->
-      <para>Hvis klienten klarer å legitimere seg ved hjelp av noen av 
-        metodene nevnt ovenfor, vil den prøve å lagre brukerdataene på 
-        disken (unntatt hvis brukeren har slått av denne oppførselen, 
-        som tidligere nevnt).</para>
-
-    </sect2>
-
-  </sect1>
-
-
-  <!-- ================================================================= -->
-  <!-- ================================================================= -->
-  <!-- ================================================================= -->
 <!-- @CHK {{ -->
   <sect1 id="svn.serverconfig.svnserve">
 
@@ -1574,7 +1057,7 @@
           client displays it in the authentication prompt, and uses it
           as a key (along with the server's hostname and port) for
           caching credentials on disk (see <xref
-          linkend="svn.serverconfig.netmodel.credcache"/>).  The
+          linkend="svn.advanced.netmodel.credcache"/>).  The
           <literal>password-db</literal> variable points to a separate
           file that contains a list of usernames and passwords, using
           the same familiar format.  For example:</para>
@@ -1586,7 +1069,7 @@
           autentiseringsinfo, og bruker det som en nøkkel (sammen med 
           &the_server;s vertsnavn og port) for å lagre legitimasjonsinfo 
           på disken (se <xref 
-          linkend="svn.serverconfig.netmodel.credcache"/>).
+          linkend="svn.advanced.netmodel.credcache"/>).
           Variabelen <literal>password-db</literal> peker til en separat 
           fil som inneholder en liste med brukernavn og passord, som 
           bruker det samme kjente formatet.
@@ -1891,7 +1374,7 @@
         program prompting for authentication, and
         <emphasis>not</emphasis> the <command>svn</command> client
         program.  That means there's no automatic password caching
-        going on (see <xref linkend="svn.serverconfig.netmodel.credcache"/>).  The
+        going on (see <xref linkend="svn.advanced.netmodel.credcache"/>).  The
         Subversion client often makes multiple connections to the
         repository, though users don't normally notice this due to the
         password caching feature.  When using
@@ -1907,7 +1390,7 @@
         <command>ssh</command>-programmet som spør etter autentisering, 
         og <emphasis>ikke</emphasis> <command>svn</command>-klienten.
         Dette betyr at det er ingen automatisk lagring av passord (se 
-        <xref linkend="svn.serverconfig.netmodel.credcache"/>).
+        <xref linkend="svn.advanced.netmodel.credcache"/>).
         Subversionklienten foretar ofte flere tilkoblinger til depotet, 
         selv om brukere vanligvis ikke legger merke til dette på grunn 
         av funksjonen som lagrer passord.
@@ -3343,7 +2826,7 @@
           will be cached in your private run-time
           <filename>auth/</filename> area in just the same way your
           username and password are cached (see <xref
-          linkend="svn.serverconfig.netmodel.credcache"/>).  If cached,
+          linkend="svn.advanced.netmodel.credcache"/>).  If cached,
           Subversion will automatically remember to trust this certificate
           in future negotiations.</para>
         @ENGLISH }}} -->
@@ -3355,7 +2838,7 @@
           <filename>auth/</filename>-område som brukes under kjøring på 
           omtrent den samme måten som brukernavnet og passordet ditt 
           blir lagret (se <xref 
-          linkend="svn.serverconfig.netmodel.credcache"/>).
+          linkend="svn.advanced.netmodel.credcache"/>).
           Hvis det blir lagret, vil Subversion automatisk huske dette 
           sertifikatet i framtidige <!-- ¤ -->forhandlinger.</para>
 
@@ -4546,13 +4029,10 @@
           increased functionality or security in Subversion as well.
           Subversion communicates with Apache using Neon, which is a
           generic HTTP/WebDAV library with support for such mechanisms
-          as SSL (the Secure Socket Layer, discussed earlier) and
-          Deflate compression (the same algorithm used by the
-          <command>gzip</command> and <command>PKZIP</command>
-          programs to <quote>shrink</quote> files into smaller chunks
-          of data).  You need only to compile support for the features
-          you desire into Subversion and Apache, and properly
-          configure the programs to use those features.</para>
+          as SSL (the Secure Socket Layer, discussed earlier).  If
+          your Subversion client is built to support SSL, then it can
+          access your Apache server
+          using <literal>https://</literal>.</para>
         @ENGLISH }}} -->
         <para>Mye av funksjonaliteten som Apache tilbyr i sin rolle som 
           en robust web&server; kan i tillegg bli <!-- ¤ Resten av 
@@ -4561,76 +4041,48 @@
           Subversion kommuniserer med Apache ved bruk av Neon, som er et 
           generelt HTTP/WebDAV-bibliotek med støtte for mekanismer som 
           SSL (<foreignphrase>Secure Socket Layer</foreignphrase>, som 
-          tidligere diskutert) og <quote>deflate</quote>-kompresjon (den 
-          samme algoritmen som brukes av programmene 
-          <command>gzip</command> og <command>PKZIP</command> for å 
-          minske størrelsen på filer).
-          Du trenger bare å kompilere støtte for den funksjonaliteten du 
-          ønsker inn i Subversion og Apache og sette programmene opp for 
-          å bruke denne funksjonaliteten.</para>
-
-        <!-- @ENGLISH {{{
-        <para>Deflate compression places a small burden on the client
-          and server to compress and decompress network transmissions
-          as a way to minimize the size of the actual transmission.
-          In cases where network bandwidth is in short supply, this
-          kind of compression can greatly increase the speed at which
-          communications between server and client can be sent.  In
-          extreme cases, this minimized network transmission could be
-          the difference between an operation timing out or completing
-          successfully.</para>
-        @ENGLISH }}} -->
-        <para><quote>Deflate</quote>-pakking øker belastningen litt på 
-          klienten og &the_server; for å pakke og pakke opp overføringer 
-          på nettverket som en måte å minske størrelsen på den faktiske 
-          overføringen.
-          I tilfeller med liten båndbredde kan dette virkelig øke 
-          hastigheten på kommunikasjonen mellom &the_server; og 
-          klienten.
-          I ekstreme tilfeller kan denne minskede nettverksoverføringen 
-          utgjøre forskjellen på enten å få et tidsavbrudd eller å 
-          fullføre operasjonen.</para>
-
-        <!-- @ENGLISH {{{
-        <para>Less interesting, but equally useful, are other features
-          of the Apache and Subversion relationship, such as the
-          ability to specify a custom port (instead of the default
-          HTTP port 80) or a virtual domain name by which the
-          Subversion repository should be accessed, or the ability to
-          access the repository through a proxy.  These things are all
-          supported by Neon, so Subversion gets that support for
-          free.</para>
-        @ENGLISH }}} -->
-        <para>Mindre interessante, men like nyttige funksjonaliteter i 
-          forholdet mellom Apache og Subversion er muligheten til å 
-          spesifisere en spesiell port (istedenfor den vanlige 
-          HTTP-porten 80) eller virtuelle domenenavn som 
-          Subversiondepoter skal aksesseres via, eller muligheten til å 
-          aksessere depotet gjennom en mellom&server;.
+          tidligere diskutert).
+          Hvis Subversionklienten din er bygget med støtte for SSL, kan 
+          den aksessere Apache&servers; via 
+          <literal>https://</literal>.</para>
+
+        <!-- @ENGLISH {{{
+        <para>Equally useful are other features of the Apache and
+          Subversion relationship, such as the ability to specify a
+          custom port (instead of the default HTTP port 80) or a
+          virtual domain name by which the Subversion repository
+          should be accessed, or the ability to access the repository
+          through an HTTP proxy.  These things are all supported by
+          Neon, so Subversion gets that support for free.</para>
+        @ENGLISH }}} -->
+        <para>Like nyttige funksjonaliteter i forholdet mellom Apache og 
+          Subversion er muligheten til å spesifisere en spesiell port 
+          (istedenfor den vanlige HTTP-porten 80) eller virtuelle 
+          domenenavn som Subversiondepoter skal aksesseres via, eller 
+          muligheten til å aksessere depotet gjennom en 
+          HTTP-mellom&server;.
           Alle disse tingene støttes av Neon, så denne støtten får 
           Subversion helt gratis.</para>
 
         <!-- @ENGLISH {{{
         <para>Finally, because <command>mod_dav_svn</command> is
-          speaking a semi-complete dialect of WebDAV/DeltaV, it's
+          speaking a subset of the WebDAV/DeltaV protocol, it's
           possible to access the repository via third-party DAV
           clients.  Most modern operating systems (Win32, OS X, and
           Linux) have the built-in ability to mount a DAV server as a
-          standard network <quote>share</quote>.  This is a
-          complicated topic; for details, read <xref
-          linkend="svn.webdav"/>.</para>
+          standard network share.  This is a complicated topic; for
+          details, read <xref linkend="svn.webdav"/>.</para>
         @ENGLISH }}} -->
-        <para>Til sist, fordi <command>mod_dav_svn</command> snakker en 
-          halvkomplett dialekt av WebDAV/DeltaV, er det mulig å 
-          aksessere depotet vie tredjeparts DAV-klienter.
+        <para>Til sist, fordi <command>mod_dav_svn</command> forstår et 
+          utvalg av WebDAV/DeltaV-protokollen, er det mulig å aksessere 
+          depotet vie tredjeparts DAV-klienter.
           De fleste moderne operativsystemer (Win32, OS X og Linux) har 
-          muligheten til å montere en DAV-&server; som en standard 
-          <quote>share</quote> (delt ressurs eller disk).
-          Dette er et kompliser tema; for detaljer, les <xref 
+          muligheten til å montere en DAV-&server; som en standard delt 
+          ressurs på nettverket.
+          Dette er et komplisert tema; for detaljer, les <xref 
           linkend="svn.webdav"/>.</para>
 <!-- @CHK }} -->
 
-
       </sect3>
 
     </sect2>
@@ -4680,8 +4132,13 @@
         and it appeases the administrator's desire to maintain tight
         control of the repository.</para>
 
-      <para>Note, though, that there are often invisible costs
-        associated with this feature.  Most of the time, while certain
+      <para>Note, though, that there are often invisible (and
+        visible!) costs associated with this feature.  In the visible
+        category, the server needs to do a lot more work to ensure
+        that the user has the right to read or write each specific
+        path; in certain situations, there's very noticeable
+        performance loss.  In the invisible category, consider the
+        culture you're creating.  Most of the time, while certain
         users <emphasis>shouldn't</emphasis> be committing changes to
         certain parts of the repository, that social contract doesn't
         need to be technologically enforced.  Teams can sometimes
@@ -4691,7 +4148,8 @@
         server level, you're setting up barriers to unexpected
         collaboration.  You're also creating a bunch of rules that
         need to be maintained as projects develop, new users are
-        added, and so on.  It's a bunch of extra work to maintain.</para>
+        added, and so on.  It's a bunch of extra work to
+        maintain.</para>
 
         <para>Remember that this is a version control system!  Even if
         somebody accidentally commits a change to something they
@@ -4703,10 +4161,11 @@
       <para>So before you begin restricting users' access rights, ask
         yourself if there's a real, honest need for this, or if it's
         just something that <quote>sounds good</quote> to an
-        administrator.  Remember that there's very little risk
-        involved, and that it's bad to become dependent on technology
-        as a crutch for social problems.<footnote><para>A common theme
-        in this book!</para></footnote>.</para>
+        administrator.  Decide whether it's worth sacrificing some
+        server speed for, and remember that there's very little risk
+        involved; it's bad to become dependent on technology as a
+        crutch for social problems.<footnote><para>A common theme in
+        this book!</para></footnote>.</para>
 
       <para>As an example to ponder, consider that the Subversion
         project itself has always a notion of who is allowed to commit
@@ -4885,18 +4344,16 @@
 
     <!-- @ENGLISH {{{
     <para>The thing to remember is that the most specific path always
-      matches first.  The <command>mod_authz_svn</command> module
-      tries to match the path itself, and then the parent of the path,
-      then the parent of that, and so on.  The net effect is that
-      mentioning a specific path in the accessfile will always
-      override any permissions inherited from parent
-      directories.</para>
+      matches first.  The server tries to match the path itself, and
+      then the parent of the path, then the parent of that, and so on.
+      The net effect is that mentioning a specific path in the
+      accessfile will always override any permissions inherited from
+      parent directories.</para>
     @ENGLISH }}} -->
     <para>Tingen å huske på er at den mest spesifikke stien alltid 
       samsvarer først.
-      <command>mod_authz_svn</command>-modulen prøver selv å få stien 
-      til å stemme, deretter forelderen til stien, så forelderen til 
-      den, og så videre.
+      &The_server; prøver å få selve stien til å stemme, deretter 
+      forelderen til stien, så forelderen til den, og så videre.
       Netteffekten er at det å nevne en spesifikk sti i aksessfila 
       alltid vil overstyre alle rettigheter som er arvet fra 
       foreldrekataloger.</para>
@@ -4926,45 +4383,39 @@
     <!-- @ENGLISH {{{
     <para>This is a common setup; notice that there's no repository
       name mentioned in the section name.  This makes all repositories
-      world readable to all users, whether you're
-      using <literal>SVNPath</literal> or
-      <literal>SVNParentPath</literal>.  Once all users have
-      read-access to the repositories, you can give explicit
+      world readable to all users. Once all users have read-access to
+      the repositories, you can give explicit
       <literal>rw</literal> permission to certain users on specific
       subdirectories within specific repositories.</para>
     @ENGLISH }}} -->
     <para>Dette er et vanlig oppsett; legg merke til at det ikke nevnes 
       noen depotnavn i seksjonsnavnet.
-      Dette gjør alle depotene fullstendig lesbare for alle brukerne, 
-      enten du bruker <literal>SVNPath</literal> eller 
-      <literal>SVNParentPath</literal>
+      Dette gjør alle depotene fullstendig lesbare for alle brukerne.
       Når alle brukerne har lesetilgang til depotene, kan du gi 
-      eksplisitt <literal>rw</literal>-rettigheter til visse brukere i 
-      spesifikke underkataloger inne i spesifikke depoter.</para>
+      eksplisitt lese/skrive-rettigheter til visse brukere i spesifikke 
+      underkataloger inne i spesifikke depoter.</para>
 
     <!-- @ENGLISH {{{
     <para>The asterisk variable (<literal>*</literal>) is also worth
       special mention here: it's the
       <emphasis>only</emphasis> pattern which matches an anonymous
-      user.  If you've configured your <literal>Location</literal>
-      block to allow a mixture of anonymous and authenticated access,
-      all users start out accessing Apache anonymously.
-      <command>mod_authz_svn</command> looks for a
+      user.  If you've configured your server block to allow a mixture
+      of anonymous and authenticated access, all users start out
+      accessing anonymously.  The server looks for a
       <literal>*</literal> value defined for the path being accessed;
-      if it can't find one, then Apache demands real authentication
-      from the client.</para>
+      if it can't find one, then it demands real authentication from
+      the client.</para>
     @ENGLISH }}} -->
     <para>Asteriskvariabelen (<literal>*</literal>) er også verdt litt 
       spesiell omtale her:
       Det er det <emphasis>eneste</emphasis> mønsteret som samsvarer med 
       en anonym bruker.
-      Hvis du har satt opp <literal>Location</literal>-blokken din til å 
-      tillate en blanding av anonym og autentisert tilgang, starter alle 
-      brukere med å aksessere Apache anonymt.
-      <command>mod_authz_svn</command> ser etter en 
-      <literal>*</literal>-verdi for stien som blir aksessert; hvis den 
-      ikke finner noen, forlanger Apache skikkelig autentisering fra 
-      klienten.</para>
+      Hvis du har satt opp &server;blokken din til å tillate en blanding 
+      av anonym og autentisert tilgang, starter alle brukere med å 
+      kommunisere anonymt.
+      &The_server; ser etter en <literal>*</literal>-verdi for stien som 
+      blir aksessert; hvis den ikke finner noen, forlanger den skikkelig 
+      autentisering fra klienten.</para>
 
     <!-- @ENGLISH {{{
     <para>The access file also allows you to define whole groups of




More information about the svnbook-dev mailing list