[svnbook commit] r1429 - in trunk/src/nb: . book
sunny256
svnbook-dev at red-bean.com
Tue Jun 7 03:12:39 CDT 2005
Author: sunny256
Date: Tue Jun 7 03:12:38 2005
New Revision: 1429
Modified:
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch06.xml
Log:
Translation in the Norwegian svnbook.
* src/nb/TRANSLATION-STATUS
ch06.xml to 11%.
* src/nb/book/ch06.xml
(svn.serverconfig.netmodel): Almost finished.
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Tue Jun 7 03:12:38 2005
@@ -35,7 +35,7 @@
2.1.2. In progress
- book/ch06.xml (5%) -- sunny256
+ book/ch06.xml (11%) -- sunny256
2.1.3. Needs update
Modified: trunk/src/nb/book/ch06.xml
==============================================================================
--- trunk/src/nb/book/ch06.xml (original)
+++ trunk/src/nb/book/ch06.xml Tue Jun 7 03:12:38 2005
@@ -278,18 +278,33 @@
<!-- ================================================================= -->
<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 -tjener kommuniserer med hverandre, uavhengig
+ av hvilken nettverksimplementasjon du bruker.
+ Etter å ha lest dette vil du ha en god forståelse av hvordan en
+ tjener 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
@@ -298,9 +313,22 @@
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
+ -ﳢ-version</command> to see which URL schemas and protocols the
client knows how to use.</para>
+ @ENGLISH }}} -->
+ <para>Subversionklienten bruker mesteparten av tiden til å
+ behandle arbeidskopier.
+ Men når den trenger informasjon fra et depot foretar den en
+ nettverksforespørsel og tjeneren 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 tjeneren (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
@@ -318,7 +346,27 @@
then the server will never issue an authentication challenge
when a client attempts to <command>svn
checkout</command>.</para>
+ @ENGLISH }}} -->
+ <para>Når tjeneren 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 tjeneren.
+ Når autentiseringen er komplett, svarer tjeneren 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 tjeneren før noen forespørsel etter informasjon
+ blir gjort.
+ I Subversion <quote>henter</quote> tjeneren 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 tjener er konfigurert til å la alle i hele
+ verden få lese depotet, vil tjeneren 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
@@ -330,16 +378,39 @@
<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, tjeneren
+ 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å tjeneren.</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 tjenere er satt opp til å forlange autentisering for
+ hver eneste forespørsel.
+ Dette kan bli et stort irrtasjonsmoment 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
@@ -352,13 +423,37 @@
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 å legitimere seg
+ ovenfor en tjener, 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 tjenernavn, 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 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 lageret 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>The security-paranoid people may be thinking to
themselves, <quote>Caching passwords on disk? That's
terrible! You should never do that!</quote> But please remain
@@ -367,10 +462,24 @@
data from it, not the world at large. If that's still not
safe enough for you, you can disable credential caching. To
disable caching for a single command, pass the
- <option>--no-auth-cache</option> option:</para>
+ <option>-ﳢ-no-auth-cache</option> option:</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.
+ For det første er lagringsområdet i <filename>auth/</filename>
+ beskyttet av rettigheter så bare brukeren (eieren) kan lese
+ dataene derfra, ikke resten av verden.
+ Hvis dette heller ikke er sikkert nok for deg, kan du slå av
+ lagringen av legitimasjonsdataene.
+ 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
+$ svn commit -F log_msg.txt -ﳢ-no-auth-cache
Authentication realm: <svn://host.example.com:3690> example realm
Username: joe
Password for 'joe':
@@ -387,6 +496,26 @@
Username: joe
[...]
</screen>
+ at 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.
+
+# 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>
<para>Or, if you want to disable credential caching permanently,
you can edit your runtime <filename>config</filename> file
More information about the svnbook-dev
mailing list