[svnbook commit] r2807 - in trunk/src/nb: . book
sunny256
noreply at red-bean.com
Fri Jun 22 08:28:22 CDT 2007
Author: sunny256
Date: Fri Jun 22 08:28:22 2007
New Revision: 2807
Log:
Sync the Norwegian and English book up to r2612.
* src/nb/book/ch-advanced-topics.xml
* src/nb/book/ch-fundamental-concepts.xml
Merged and updated r2607, r2608, r2609, r2610, r2611, r2612.
* src/nb/TRANSLATION-STATUS
* src/nb/LAST_SYNC
Automatically updated.
Modified:
trunk/src/nb/LAST_SYNC
trunk/src/nb/TRANSLATION-STATUS
trunk/src/nb/book/ch-advanced-topics.xml
trunk/src/nb/book/ch-fundamental-concepts.xml
Modified: trunk/src/nb/LAST_SYNC
==============================================================================
--- trunk/src/nb/LAST_SYNC (original)
+++ trunk/src/nb/LAST_SYNC Fri Jun 22 08:28:22 2007
@@ -1 +1 @@
-2606
+2612
Modified: trunk/src/nb/TRANSLATION-STATUS
==============================================================================
--- trunk/src/nb/TRANSLATION-STATUS (original)
+++ trunk/src/nb/TRANSLATION-STATUS Fri Jun 22 08:28:22 2007
@@ -18,8 +18,8 @@
* book/ch-basic-usage.xml
Untranslated: 4.31% - 108 lines in 8 blocks
* book/ch-advanced-topics.xml
- Untranslated: 76.16% - 2085 lines in 9 blocks
- Need proofreading: 19.59% - 575 lines in 2 blocks
+ Untranslated: 76.43% - 2139 lines in 9 blocks
+ Need proofreading: 19.50% - 577 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
@@ -49,4 +49,4 @@
* book/index.xml
Translation complete
-Summa summarum: 58.43% translated, 17.15% need proofreading
+Summa summarum: 58.36% translated, 17.14% 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 Fri Jun 22 08:28:22 2007
@@ -35,15 +35,13 @@
<!-- @ENGLISH {{{
<para>But the Subversion feature set doesn't stop at <quote>common
version control operations</quote>. It has other bits of
- functionality that extend beyond basic file and directory
- versioning; beyond just sending and receiving changes to and from
- a central repository.</para>
+ functionality that extend beyond just communicating file and
+ directory changes to and from a central repository.</para>
@ENGLISH }}} -->
<para>Men funksjonaliteten til Subversion stopper ikke ved
<quote>vanlige versjonskontrolloperasjoner</quote>.
- Den har annen funksjonalitet som går forbi grunnleggende fil- og
- katalogversjonering; forbi det å bare sende og motta forandringer
- til og fra et sentralt depot.</para>
+ Den har annen funksjonalitet som går forbi det å bare sende fil- og
+ katalogforandringer til og fra et sentralt depot.</para>
<!-- @ENGLISH {{{
<para>This chapter highlights some of Subversion's features that,
@@ -74,7 +72,7 @@
<!-- @TR {{ -->
<title>Revision Specifiers</title>
- <para>As we saw in <xref linkend="svn.tour.revs" />, revision
+ <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
versioned data. Still, it doesn't take long before you can no
@@ -202,14 +200,10 @@
<!-- @TR }} -->
<!-- @ENGLISH {{{
- <para>Here are some examples of revision keywords in action.
- Don't worry if the commands don't make sense yet; we'll be
- explaining these commands as we go through the chapter:</para>
- @ENGLISH }}} -->
- <para>Her er noen eksempler på revisjonsnøkkelord i aksjon.
- Ikke bli urolig om du ikke forstår den fulle betydningen av
- kommandoene enda; vi vil forklare disse kommandoene mens vi går
- gjennom kapittelet:</para>
+ <para>Here are some examples of revision keywords in
+ action:</para>
+ @ENGLISH }}} -->
+ <para>Her er noen eksempler på revisjonsnøkkelord i aksjon:</para>
<!-- @ENGLISH {{{
<screen>
@@ -291,32 +285,32 @@
<!-- @ENGLISH {{{
<screen>
-$ svn checkout -r {2002-02-17}
+$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
-$ svn checkout -r {"2002-02-17 15:30"}
-$ svn checkout -r {"2002-02-17 15:30 +0230"}
-$ svn checkout -r {2002-02-17T15:30}
-$ svn checkout -r {2002-02-17T15:30Z}
-$ svn checkout -r {2002-02-17T15:30-04:00}
-$ svn checkout -r {20020217T1530}
-$ svn checkout -r {20020217T1530Z}
-$ svn checkout -r {20020217T1530-0500}
+$ svn checkout -r {"2006-02-17 15:30"}
+$ svn checkout -r {"2006-02-17 15:30 +0230"}
+$ svn checkout -r {2006-02-17T15:30}
+$ svn checkout -r {2006-02-17T15:30Z}
+$ svn checkout -r {2006-02-17T15:30-04:00}
+$ svn checkout -r {20060217T1530}
+$ svn checkout -r {20060217T1530Z}
+$ svn checkout -r {20060217T1530-0500}
…
</screen>
@ENGLISH }}} -->
<screen>
-$ svn checkout -r {2002-02-17}
+$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
-$ svn checkout -r {"2002-02-17 15:30"}
-$ svn checkout -r {"2002-02-17 15:30 +0230"}
-$ svn checkout -r {2002-02-17T15:30}
-$ svn checkout -r {2002-02-17T15:30Z}
-$ svn checkout -r {2002-02-17T15:30-04:00}
-$ svn checkout -r {20020217T1530}
-$ svn checkout -r {20020217T1530Z}
-$ svn checkout -r {20020217T1530-0500}
+$ svn checkout -r {"2006-02-17 15:30"}
+$ svn checkout -r {"2006-02-17 15:30 +0230"}
+$ svn checkout -r {2006-02-17T15:30}
+$ svn checkout -r {2006-02-17T15:30Z}
+$ svn checkout -r {2006-02-17T15:30-04:00}
+$ svn checkout -r {20060217T1530}
+$ svn checkout -r {20060217T1530Z}
+$ svn checkout -r {20060217T1530-0500}
…
</screen>
@@ -329,16 +323,16 @@
<!-- @ENGLISH {{{
<screen>
-$ svn log -r {2002-11-28}
+$ svn log -r {2006-11-28}
-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-ﳢ-
-r12 | ira | 2002-11-27 12:31:51 -0600 (Wed, 27 Nov 2002) | 6 lines
+r12 | ira | 2006-11-27 12:31:51 -0600 (Mon, 27 Nov 2006) | 6 lines
…
</screen>
@ENGLISH }}} -->
<screen>
-$ svn log -r {2002-11-28}
+$ svn log -r {2006-11-28}
------------------------------------------------------------------------
-r12 | ira | 2002-11-27 12:31:51 -0600 (ons, 27 nov 2002) | 6 lines
+r12 | ira | 2006-11-27 12:31:51 -0600 (man, 27 nov 2006) | 6 lines
…
</screen>
@@ -351,20 +345,20 @@
<!-- @ENGLISH {{{
<para>If you specify a single date as a revision without
specifying a time of day (for example
- <literal>2002-11-27</literal>), you may think that Subversion
+ <literal>2006-11-27</literal>), you may think that Subversion
should give you the last revision that took place on the
27th of November. Instead, you'll get back a revision from
the 26th, or even earlier. Remember that Subversion will
find the <emphasis>most recent revision of the
repository</emphasis> as of the date you give. If you give
a date without a timestamp, like
- <literal>2002-11-27</literal>, Subversion assumes a time of
+ <literal>2006-11-27</literal>, Subversion assumes a time of
00:00:00, so looking for the most recent revision won't
return anything on the day of the 27th.</para>
@ENGLISH }}} -->
<para>Hvis du spesifiserer en enkelt dato som en revisjon uten å
spesifisere klokkeslett (for eksempel
- <literal>2002-11-27</literal>, forventer du kanskje at
+ <literal>2006-11-27</literal>, forventer du kanskje at
Subversion skal gi deg den siste revisjonen som ble opprettet
27. november.
Istedenfor får du en revisjon fra den 26., eller til og med
@@ -372,21 +366,21 @@
Husk at Subversion vil finne den <emphasis>nyeste versjonen i
depotet</emphasis> på den datoen du oppgir.
Hvis du angir en dato uten klokkeslett, som
- <literal>2002-11-27</literal>, bruker Subversion klokkeslettet
+ <literal>2006-11-27</literal>, bruker Subversion klokkeslettet
00:00:00, så det å se etter den nyeste revisjonen vil ikke
returnere noe som helst fra denne datoen.</para>
<!-- @ENGLISH {{{
<para>If you want to include the 27th in your search, you can
- either specify the 27th with the time (<literal>{"2002-11-27
+ either specify the 27th with the time (<literal>{"2006-11-27
23:59"}</literal>), or just specify the next day
- (<literal>{2002-11-28}</literal>).</para>
+ (<literal>{2006-11-28}</literal>).</para>
@ENGLISH }}} -->
<para>Hvis du ønsker å inkludere den 27de i letingen, kan du
enten spesifisere den 27de med klokkeslett
- (<literal>{"2002-11-27 23:59"}</literal>, eller bare
+ (<literal>{"2006-11-27 23:59"}</literal>, eller bare
spesifisere den neste dagen
- (<literal>{2002-11-28}</literal>).</para>
+ (<literal>{2006-11-28}</literal>).</para>
</sidebar>
@@ -400,12 +394,12 @@
<!-- @ENGLISH {{{
<screen>
-$ svn log -r {2002-11-20}:{2002-11-29}
+$ svn log -r {2006-11-20}:{2006-11-29}
…
</screen>
@ENGLISH }}} -->
<screen>
-$ svn log -r {2002-11-20}:{2002-11-29}
+$ svn log -r {2006-11-20}:{2006-11-29}
…
</screen>
@@ -464,10 +458,10 @@
flexibility for versioned files as you'd expect when
manipulating your unversioned ones. But that flexibility means
that across the lifetime of your repository, a given versioned
- resource might have many paths, and a given path might represent
- several entirely different versioned resources. And this
+ object might have many paths, and a given path might represent
+ several entirely different versioned objects. And this
introduces a certain level of complexity to your interactions
- with those paths and resources.</para>
+ with those paths and objects.</para>
<para>Subversion is pretty smart about noticing when an object's
version history includes such <quote>changes of address</quote>.
@@ -493,7 +487,7 @@
ever lived at that path? Clearly, Subversion needs a hint about
what you really want.</para>
- <para>And thanks to moves, versioned resource history can get far
+ <para>And thanks to moves, versioned object history can get far
more twisted than that, even. For example, you might have a
directory named <filename>concept</filename>, containing some
nascent software project you've been toying with. Eventually,
@@ -539,7 +533,7 @@
it exactly which Main Street you meant. It's called the
<firstterm>peg revision</firstterm>, and it is a revision
provided to Subversion for the sole purpose of identifying a
- unique line of history. Because at most one versioned resource
+ unique line of history. Because at most one versioned object
may occupy a path at any given time—or, more precisely, in
any one revision—the combination of a path and a peg
revision is all that is needed to refer to a specific line of
@@ -573,13 +567,13 @@
go.</para>
<sidebar>
- <title>The "peg-revision" algorithm</title>
+ <title>The peg revision algorithm</title>
- <para>The Subversion command-line performs the peg-revision
- algorithm basically any time it needs to resolve possible
- ambiguities in the paths and revisions provided to it. Here's
- an example of such an invocation for the purposes of
- illustrating that algorithm.</para>
+ <para>The Subversion command-line performs the peg revision
+ algorithm any time it needs to resolve possible ambiguities in
+ the paths and revisions provided to it. Here's an example of
+ such an invocation for the purposes of illustrating that
+ algorithm.</para>
<screen>
$ svn <replaceable>command</replaceable> -r <replaceable>OPERATIVE-REV</replaceable> item@<replaceable>PEG-REV</replaceable>
@@ -643,7 +637,6 @@
<screen>
$ svn cat -r 1 concept/IDEA
-subversion/libsvn_client/ra.c:775: (apr_err=20014)
svn: Unable to find repository location for 'concept/IDEA' in revision 1
</screen>
@@ -655,7 +648,6 @@
<screen>
$ svn cat -r 1 concept/IDEA at BASE
-subversion/libsvn_client/ra.c:775: (apr_err=20014)
svn: Unable to find repository location for 'concept/IDEA' in revision 1
</screen>
@@ -1167,13 +1159,13 @@
<!-- @ENGLISH {{{
<screen>
-$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
+$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c
property 'copyright' set on 'calc/button.c'
$
</screen>
@ENGLISH }}} -->
<screen>
-$ svn propset copyright '(c) 2003 Red-Bean Software' calc/button.c
+$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c
Egenskapen «copyright» satt på «calc/button.c»
$
</screen>
@@ -1305,7 +1297,7 @@
<!-- @ENGLISH {{{
<screen>
-$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
+$ svn propset copyright '(c) 2006 Red-Bean Software' calc/*
property 'copyright' set on 'calc/Makefile'
property 'copyright' set on 'calc/button.c'
property 'copyright' set on 'calc/integer.c'
@@ -1314,7 +1306,7 @@
</screen>
@ENGLISH }}} -->
<screen>
-$ svn propset copyright '(c) 2002 Red-Bean Software' calc/*
+$ svn propset copyright '(c) 2006 Red-Bean Software' calc/*
Egenskapen «copyright» satt på «calc/Makefile»
Egenskapen «copyright» satt på «calc/button.c»
Egenskapen «copyright» satt på «calc/integer.c»
@@ -1356,7 +1348,7 @@
copyright
license
$ svn propget copyright calc/button.c
-(c) 2003 Red-Bean Software
+(c) 2006 Red-Bean Software
</screen>
@ENGLISH }}} -->
<screen>
@@ -1365,7 +1357,7 @@
copyright
license
$ svn propget copyright calc/button.c
-(c) 2003 Red-Bean Software
+(c) 2006 Red-Bean Software
</screen>
<!-- @ENGLISH {{{
@@ -1384,9 +1376,9 @@
<screen>
$ svn proplist -ﳢ-verbose calc/button.c
Properties on 'calc/button.c':
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
license : ================================================================
-Copyright (c) 2003 Red-Bean Software. All rights reserved.
+Copyright (c) 2006 Red-Bean Software. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
@@ -1402,9 +1394,9 @@
<screen>
$ svn proplist --verbose calc/button.c
Egenskaper for «calc/button.c»:
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
license : ================================================================
-Copyright (c) 2003 Red-Bean Software. All rights reserved.
+Copyright (c) 2006 Red-Bean Software. All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
@@ -1439,7 +1431,7 @@
property 'license' set on 'calc/button.c'
$ svn proplist -ﳢ-verbose calc/button.c
Properties on 'calc/button.c':
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
license :
$
</screen>
@@ -1449,7 +1441,7 @@
Egenskapen «license» satt på «calc/button.c»
$ svn proplist --verbose calc/button.c
Egenskaper for «calc/button.c»:
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
license :
$
</screen>
@@ -1469,7 +1461,7 @@
property 'license' deleted from 'calc/button.c'.
$ svn proplist -ﳢ-verbose calc/button.c
Properties on 'calc/button.c':
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
$
</screen>
@ENGLISH }}} -->
@@ -1478,7 +1470,7 @@
Egenskapen «license» slettet fra «calc/button.c».
$ svn proplist --verbose calc/button.c
Egenskaper for 'calc/button.c':
- copyright : (c) 2003 Red-Bean Software
+ copyright : (c) 2006 Red-Bean Software
$
</screen>
@@ -1594,7 +1586,9 @@
value of the property they are about to change, which helps
them to verify that they are, in fact, making the change
they think they are making. This is especially true when
- modifying unversioned revision properties.</para>
+ modifying unversioned revision properties. Also, it is
+ significantly easier to modify multiline property values in
+ a text editor than at the command line.</para>
@ENGLISH }}} -->
<para>Brukere bør, der det er mulig, bruke <command>svn
propedit</command> istedenfor <command>svn propset</command>.
@@ -1603,7 +1597,10 @@
forandre, noe som hjelper dem å kontrollere at de faktisk gjør
den endringen som de tror de gjør.
Dette gjelder spesielt for modifisering av uversjonerte
- revisjonsegenskaper.</para>
+ revisjonsegenskaper.
+ I tillegg er det betraktelig enklere å redigere egenskaper som
+ strekker seg over flere linjer i en tekstbehandler enn på
+ kommandolinja.</para>
</tip>
</sect2>
@@ -1667,7 +1664,7 @@
Property changes on: calc/button.c
___________________________________________________________________
Name: copyright
- + (c) 2003 Red-Bean Software
+ + (c) 2006 Red-Bean Software
$
</screen>
@@ -1679,7 +1676,7 @@
Egenskapsforandringer på: calc/button.c
___________________________________________________________________
Navn: copyright
- + (c) 2003 Red-Bean Software
+ + (c) 2006 Red-Bean Software
$
</screen>
@@ -1713,16 +1710,16 @@
<para>As with file contents, local property modifications can
conflict with changes committed by someone else. If you
update your working copy directory and receive property
- changes on a versioned resource that clash with your own,
- Subversion will report that the resource is in a conflicted
+ changes on a versioned object that clash with your own,
+ Subversion will report that the object is in a conflicted
state.</para>
@ENGLISH }}} -->
<para>I likhet med filinnhold, kan lokale egenskapsforandringene
komme i konflikt med forandringer som er lagt inn av noen
andre.
Hvis du oppdaterer arbeidskopikatalogen og mottar
- egenskapsforandringer på en versjonert ressurs som kolliderer
- med dine egne, vil Subversion rapportere at ressursen er i en
+ egenskapsforandringer på et versjonert objekt som kolliderer
+ med dine egne, vil Subversion rapportere at objektet er i en
konflikttilstand.</para>
<!-- @ENGLISH {{{
@@ -1744,24 +1741,24 @@
<!-- @ENGLISH {{{
<para>Subversion will also create, in the same directory as
- the conflicted resource, a file with a
+ the conflicted object, a file with a
<filename>.prej</filename> extension which contains the
details of the conflict. You should examine the contents of
this file so you can decide how to resolve the conflict.
Until the conflict is resolved, you will see a
<literal>C</literal> in the second column of <command>svn
- status</command> output for that resource, and attempts to
+ status</command> output for that object, and attempts to
commit your local modifications will fail.</para>
@ENGLISH }}} -->
<para>Subversion vil også lage, i den samme katalogen som
- ressursen som har en konflikt, en fil med etternavnet
+ objektet som har en konflikt, en fil med etternavnet
<filename>.prej</filename> som inneholder detaljene om
konflikten.
Du kan studere innholdet av denne fila så du kan avgjøre
hvordan konflikten skal løses.
Inntil konflikten er løst, vil du se en <literal>C</literal> i
den andre kolonnen av <command>svn status</command>-utskriften
- for denne ressursen, og forsøk på å legge inn dine lokale
+ for dette objektet, og forsøk på å legge inn dine lokale
forandringer vil feile.</para>
<!-- @ENGLISH {{{
@@ -1888,24 +1885,26 @@
linkend="svn.advanced.props.special.mime-type" />.)</para>
<para>Subversion also provides, via its runtime configuration
- system, a more flexible automatic property setting feature
- which allows you to create mappings of filename patterns to
- property names and values. Once again, these mappings affect
- adds and imports, and not only can override the default MIME
- type decision made by Subversion during those operations, but
- can also set additional Subversion or custom properties, too.
- For example, you might create a mapping that says that any
- time you add JPEG files—ones that match the pattern
+ system (see <xref linkend="svn.advanced.confarea" />), a more
+ flexible automatic property setting feature which allows you
+ to create mappings of filename patterns to property names and
+ values. Once again, these mappings affect adds and imports,
+ and not only can override the default MIME type decision made
+ by Subversion during those operations, but can also set
+ additional Subversion or custom properties, too. For example,
+ you might create a mapping that says that any time you add
+ JPEG files—ones that match the pattern
<literal>*.jpg</literal>—Subversion should automatically
set the <literal>svn:mime-type</literal> property on those
files to <literal>image/jpeg</literal>. Or perhaps any files
that match <literal>*.cpp</literal> should have
<literal>svn:eol-style</literal> set to
<literal>native</literal>, and <literal>svn:keywords</literal>
- set to <literal>Id</literal>. Auto-prop support is perhaps
- the handiest property related tool in the Subversion toolbox.
- See <xref linkend="svn.advanced.confarea.opts.config"/> for
- more about configuring that support.</para>
+ set to <literal>Id</literal>. Automatic property support is
+ perhaps the handiest property related tool in the Subversion
+ toolbox. See <xref
+ linkend="svn.advanced.confarea.opts.config"/> for more about
+ configuring that support.</para>
</sect2>
</sect1>
@@ -1918,10 +1917,10 @@
<para>Fortunately for Subversion users who routinely find
themselves on different computers with different operating
- systems, Subversion's command-line programs almost universally
- behave identically across all those systems. If you know how to
- wield <command>svn</command> on one platform, you know how to
- wield it everywhere.</para>
+ systems, Subversion's command-line program behaves almost
+ identically on all those systems. If you know how to wield
+ <command>svn</command> on one platform, you know how to wield it
+ everywhere.</para>
<para>However, the same is not always true of other general classes
of software, or of the actual files you keep in Subversion. For
@@ -2206,13 +2205,13 @@
<para>In any given working copy there is a good chance that
alongside all those versioned files and directories are other
- files and directories which are not, and are not intended to be,
- themselved versioned. Text editors litter directories with
- backup files. Code compilation processes generate
- intermediate—or even final—files which you typically
- wouldn't bother to version. And users themselves drop various
- other files and directories wherever they see fit, often in
- version control working copies.</para>
+ files and directories which are neither versioned nor intended
+ to be. Text editors litter directories with backup files. Code
+ compilation processes generate intermediate—or even
+ final—files which you typically wouldn't bother to
+ version. And users themselves drop various other files and
+ directories wherever they see fit, often in version control
+ working copies.</para>
<para>It's ludicrous to expect Subversion working copies to be
somehow impervious to this kind of clutter and impurity. In
@@ -2233,13 +2232,14 @@
<para>So Subversion provides a pair of ways for telling it which
files you would prefer that it simply disregard. One of the
ways involves the use of Subversion's runtime configuration
- system, and therefore applies to all the Subversion operations
- which make use of that runtime configuration, generally those
- performed on a particular computer, or by a particular user of a
- computer. The other way makes use of Subversion's directory
- property support, is more tightly bound to the versioned tree
- itself, and therefore affects everyone who has a working copy of
- that tree. Both of the mechanisms use file patterns.</para>
+ system (see <xref linkend="svn.advanced.confarea" />), and
+ therefore applies to all the Subversion operations which make
+ use of that runtime configuration, generally those performed on
+ a particular computer, or by a particular user of a computer.
+ The other way makes use of Subversion's directory property
+ support, is more tightly bound to the versioned tree itself, and
+ therefore affects everyone who has a working copy of that tree.
+ Both of the mechanisms use file patterns.</para>
<para>The Subversion runtime configuration system provides an
option, <literal>global-ignores</literal>, whose value is a
@@ -2282,7 +2282,7 @@
to avoid committing changes you've made to a versioned file
simply because that file's name matches an ignore
pattern—Subversion <emphasis>always</emphasis> notices
- all of its versioned resources.</para>
+ all of its versioned objects.</para>
</warning>
<sidebar>
@@ -2463,7 +2463,7 @@
<para>This keyword describes the last time the file was
known to have been changed in the repository, and
looks something like <literal>$Date:
- 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002)
+ 2006-07-22 21:42:37 -0700 (Sat, 22 Jul 2006)
$</literal>. It may also be specified as
<literal>LastChangedDate</literal>.</para>
</listitem>
@@ -2505,10 +2505,10 @@
<listitem>
<para>This keyword is a compressed combination of the
other keywords. Its substitution looks something like
- <literal>$Id: calc.c 148 2002-07-28 21:30:43Z sally
+ <literal>$Id: calc.c 148 2006-07-28 21:30:43Z sally
$</literal>, and is interpreted to mean that the file
<filename>calc.c</filename> was last changed in revision
- 148 on the evening of July 28, 2002 by the user
+ 148 on the evening of July 28, 2006 by the user
<literal>sally</literal>.</para>
</listitem>
</varlistentry>
@@ -2567,25 +2567,6 @@
will not substitute keywords that are not present in the
<literal>svn:keywords</literal> property value.</para>
- <sidebar>
- <title>Keywords and Spurious Differences</title>
-
- <para>The user-visible result of keyword substitution might
- lead you to think that every version of a file with that
- feature in use differs from the previous version in at
- least the area where the keyword anchor was placed.
- However, this is actually not the case. While checking
- for local modifications during <command>svn
- diff</command>, and before transmitting those local
- modifications during <command>svn commit</command>,
- Subversion <quote>un-substitutes</quote> any keywords that
- it previously substituted. The result is that the
- versions of the file that are stored in the repository
- contain only the real modifications that users make to the
- file.</para>
-
- </sidebar>
-
<para>Immediately after you commit this property change,
Subversion will update your working file with the new
substitute text. Instead of seeing your keyword anchor
@@ -2603,7 +2584,7 @@
<screen>
Here is the latest report from the front lines.
-$LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $
+$LastChangedDate: 2006-07-22 21:42:37 -0700 (Sat, 22 Jul 2006) $
$Rev$
Cumulus clouds are appearing more frequently as summer approaches.
</screen>
@@ -2616,6 +2597,34 @@
file will be re-substituted with information that
reflects the most recent known commit to that file.</para>
+ <sidebar>
+ <title>Where's $GlobalRev$?</title>
+
+ <para>New users are often confused by how the
+ <literal>$Rev$</literal> keyword works. Since the repository
+ has a single, globally increasing revision number, many people
+ assume that it is this number which is reflected by the
+ <literal>$Rev$</literal> keyword's value. But
+ <literal>$Rev$</literal> expands to show the last revision in
+ which the file <emphasis>changed</emphasis>, not the last
+ revision to which it was updated. Understanding this clears
+ the confusion, but frustration often remains—without the
+ support of a Subversion keyword to do so, how can you
+ automatically get the global revision number into your
+ files?</para>
+
+ <para>To do this, you need external processing. Subversion
+ ships with a tool called <command>svnversion</command> which
+ was designed for just this purpose.
+ <command>svnversion</command> crawls your working copy and
+ generates as output the revision(s) it finds. You can use
+ this program, plus some additionally tooling, to embed that
+ revision information into your files. For more information on
+ <command>svnversion</command>, see <xref
+ linkend="svn.ref.svnversion"/>.</para>
+
+ </sidebar>
+
<para>Subversion 1.2 introduced a new variant of the keyword
syntax which brought additional, useful—though perhaps
atypical—functionality. You can now tell Subversion
@@ -2720,17 +2729,17 @@
<title>Locking</title>
<para>Subversion's copy-modify-merge version control model lives
- and dies by the granularity of the data merging algorithms
- employed when trying to resolve conflicts caused by multiple
- users modifying the same file concurrently. Subversion itself
- provides only one such algorithm, a three-way differencing
- algorithm which is smart enough to handle data at a granularity
- of a single line of text. Subversion also allows you to
- supplement its content merge processing with external
+ and dies on its data merging algorithms, specifically on how
+ well those algorithms perform when trying to resolve conflicts
+ caused by multiple users modifying the same file concurrently.
+ Subversion itself provides only one such algorithm, a three-way
+ differencing algorithm which is smart enough to handle data at a
+ granularity of a single line of text. Subversion also allows
+ you to supplement its content merge processing with external
differencing utilities (as described in <xref
- linkend="svn.advanced.externaldifftools.diff3" />), some of which
- may do an even better job, perhaps providing granularity of a
- word or a single character of text. But common among those
+ linkend="svn.advanced.externaldifftools.diff3" />), some of
+ which may do an even better job, perhaps providing granularity
+ of a word or a single character of text. But common among those
algorithms is that they generally work only on text files. The
landscape starts to look pretty grim when you start talking
about content merges of non-textual file formats. And when you
@@ -2799,8 +2808,9 @@
thing. And this where Subversion's implementation of the
lock-modify-unlock model steps into the spotlight. This is
where we talk about Subversion's <firstterm>locking</firstterm>
- feature, which is similar to the reserved checkouts mechanisms
- of other version control systems.</para>
+ feature, which is similar to the <quote>reserved
+ checkouts</quote> mechanisms of other version control
+ systems.</para>
<para>Subversion's locking feature serves two main
purposes:</para>
@@ -2808,18 +2818,17 @@
<itemizedlist>
<listitem>
<para><emphasis>Serializing access to a versioned
- resource</emphasis>. But allowing a user to
+ object</emphasis>. By allowing a user to
programmatically claim the exclusive right to change to a
file in the repository, that user can be reasonably
confident that energy invested on unmergeable changes won't
- be wasted; that his commit of those changes will
- succeed.</para>
+ be wasted—his commit of those changes will succeed.</para>
</listitem>
<listitem>
<para><emphasis>Aiding communication</emphasis>. By alerting
other users that serialization is in effect for particular
- versioned resource, those other users can reasonably expect
- that the resource is about to be changed by someone else,
+ versioned object, those other users can reasonably expect
+ that the object is about to be changed by someone else,
and they, too, can avoid wasting their time and energy on
unmergeable changes that won't be committable due to eventual
out-of-dateness.</para>
@@ -2902,9 +2911,9 @@
the <command>svn lock</command> command.</para>
<screen>
-[harry] $ svn lock banana.jpg --message "Editing file for tomorrow's release."
+$ svn lock banana.jpg --message "Editing file for tomorrow's release."
'banana.jpg' locked by user 'harry'.
-[harry] $
+$
</screen>
<para>There are a number of new things demonstrated in the
@@ -2935,10 +2944,10 @@
info</command> reporting subcommands.</para>
<screen>
-[harry] $ svn status
+$ svn status
K banana.jpg
-[harry] $ svn info banana.jpg
+$ svn info banana.jpg
Path: banana.jpg
Name: banana.jpg
URL: http://svn.example.com/repos/project/banana.jpg
@@ -2948,17 +2957,17 @@
Schedule: normal
Last Changed Author: frank
Last Changed Rev: 1950
-Last Changed Date: 2005-03-15 12:43:04 -0600 (Tue, 15 Mar 2005)
-Text Last Updated: 2005-06-08 19:23:07 -0500 (Wed, 08 Jun 2005)
-Properties Last Updated: 2005-06-08 19:23:07 -0500 (Wed, 08 Jun 2005)
+Last Changed Date: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)
+Text Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
+Properties Last Updated: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Checksum: 3b110d3b10638f5d1f4fe0f436a5a2a5
Lock Token: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
Lock Owner: harry
-Lock Created: 2005-06-14 17:20:31 -0500 (Tue, 14 Jun 2005)
+Lock Created: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)
Lock Comment (1 line):
Editing file for tomorrow's release.
-[harry] $
+$
</screen>
<para>That the <command>svn info</command> command, which does
@@ -3002,15 +3011,15 @@
Sally is unable to change or delete that file:</para>
<screen>
-[sally] $ svn delete banana.jpg
+$ svn delete banana.jpg
D banana.jpg
-[sally] $ svn commit -m "Delete useless file."
+$ svn commit -m "Delete useless file."
Deleting banana.jpg
svn: Commit failed (details follow):
svn: DELETE of
'/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/banana.jpg':
423 Locked (http://svn.example.com)
-[sally] $
+$
</screen>
<para>But Harry, after touching up the banana's shade of yellow,
@@ -3019,14 +3028,14 @@
copy holds the correct lock token:</para>
<screen>
-[harry] $ svn status
+$ svn status
M K banana.jpg
-[harry] $ svn commit -m "Make banana more yellow"
+$ svn commit -m "Make banana more yellow"
Sending banana.jpg
Transmitting file data .
Committed revision 2201.
-[harry] $ svn status
-[harry] $
+$ svn status
+$
</screen>
<para>Notice that after the commit is finished, <command>svn
@@ -3061,7 +3070,7 @@
simple <command>svn unlock</command> command:</para>
<screen>
-[harry] $ svn unlock banana.c
+$ svn unlock banana.c
'banana.c' unlocked.
</screen>
@@ -3076,12 +3085,12 @@
these is <command>svn status --show-updates</command>:</para>
<screen>
-[sally] $ svn status --show-updates
+$ svn status --show-updates
M 23 bar.c
M O 32 raisin.jpg
* 72 foo.h
Status against revision: 105
-[sally] $
+$
</screen>
<para>In this example, Sally can see not only that her copy of
@@ -3096,7 +3105,7 @@
answers:</para>
<screen>
-[sally] $ svn info http://svn.example.com/repos/project/raisin.jpg
+$ svn info http://svn.example.com/repos/project/raisin.jpg
Path: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
@@ -3105,13 +3114,13 @@
Node Kind: file
Last Changed Author: sally
Last Changed Rev: 32
-Last Changed Date: 2005-01-25 12:43:04 -0600 (Tue, 25 Jan 2005)
+Last Changed Date: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
-Lock Created: 2005-02-16 13:29:18 -0500 (Wed, 16 Feb 2005)
+Lock Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Lock Comment (1 line):
Need to make a quick tweak to this image.
-[sally] $
+$
</screen>
<para>Just as <command>svn info</command> can be used to examine
@@ -3157,11 +3166,11 @@
<xref linkend="svn.reposadmin.maint.tk"/>.)</para>
<screen>
-[admin] $ svnadmin lslocks /usr/local/svn/repos
+$ svnadmin lslocks /usr/local/svn/repos
Path: /project2/images/banana.jpg
UUID Token: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
Owner: frank
-Created: 2005-06-15 13:29:18 -0500 (Wed, 15 Jun 2005)
+Created: 2006-06-15 13:29:18 -0500 (Thu, 15 Jun 2006)
Expires:
Comment (1 line):
Still improving the yellow color.
@@ -3169,39 +3178,39 @@
Path: /project/raisin.jpg
UUID Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Owner: harry
-Created: 2005-02-16 13:29:18 -0500 (Wed, 16 Feb 2005)
+Created: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Expires:
Comment (1 line):
Need to make a quick tweak to this image.
-[admin] $ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
+$ svnadmin rmlocks /usr/local/svn/repos /project/raisin.jpg
Removed lock on '/project/raisin.jpg'.
-[admin] $
+$
</screen>
<para>The more interesting option is allowing users to break
- each other's locks over the network. To do this, one simply
+ each other's locks over the network. To do this, Sally simply
needs to pass the <option>--force</option> to the unlock
command:</para>
<screen>
-[sally] $ svn status --show-updates
+$ svn status --show-updates
M 23 bar.c
M O 32 raisin.jpg
* 72 foo.h
Status against revision: 105
-[sally] $ svn unlock raisin.jpg
+$ svn unlock raisin.jpg
svn: 'raisin.jpg' is not locked in this working copy
-[sally] $ svn info raisin.jpg | grep URL
+$ svn info raisin.jpg | grep URL
URL: http://svn.example.com/repos/project/raisin.jpg
-[sally] $ svn unlock http://svn.example.com/repos/project/raisin.jpg
+$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: Unlock request failed: 403 Forbidden (http://svn.example.com)
-[sally] $ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
+$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
'raisin.jpg' unlocked.
-[sally] $
+$
</screen>
- <para>Sally's initial attempt to unlock failed because she
+ <para>Now, Sally's initial attempt to unlock failed because she
ran <command>svn unlock</command> directly on her working copy
of the file, and no lock token was present. To remove the
lock directly from the repository, she needs to pass a URL
@@ -3221,15 +3230,15 @@
might lock the file between the two commands. The simpler thing
to is <firstterm>steal</firstterm> the lock, which involves
breaking and re-locking the file all in one atomic step. To
- do this, pass the <option>--force</option> option
+ do this, Sally passes the <option>--force</option> option
to <command>svn lock</command>:</para>
<screen>
-[sally] $ svn lock raisin.jpg
+$ svn lock raisin.jpg
svn: Lock request failed: 423 Locked (http://svn.example.com)
-[sally] $ svn lock --force raisin.jpg
+$ svn lock --force raisin.jpg
'raisin.jpg' locked by user 'sally'.
-[sally] $
+$
</screen>
<para>In any case, whether the lock is broken or stolen, Harry
@@ -3243,14 +3252,14 @@
repository:</para>
<screen>
-[harry] $ svn status
+$ svn status
K raisin.jpg
-[harry] $ svn status --show-updates
+$ svn status --show-updates
B 32 raisin.jpg
-[harry] $ svn update
+$ svn update
B raisin.jpg
-[harry] $ svn status
-[harry] $
+$ svn status
+$
</screen>
<para>If the repository lock was broken, then <command>svn
@@ -3338,19 +3347,19 @@
discovers the pre-existing lock:</para>
<screen>
-[sally] $ /usr/local/bin/gimp raisin.jpg
+$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
-[sally] $ ls -l raisin.jpg
+$ ls -l raisin.jpg
-r--r--r-- 1 sally sally 215589 Jun 8 19:23 raisin.jpg
-[sally] $ svn lock raisin.jpg
+$ svn lock raisin.jpg
svn: Lock request failed: 423 Locked (http://svn.example.com)
-[sally] $ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
+$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
Lock Token: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Lock Owner: harry
-Lock Created: 2005-06-08 07:29:18 -0500 (Thu, 08 June 2005)
+Lock Created: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Lock Comment (1 line):
Making some tweaks. Locking for the next two hours.
-[sally] $
+$
</screen>
<tip>
@@ -3406,7 +3415,7 @@
<firstterm>externals definitions</firstterm>. An externals
definition is a mapping of a local directory to the
URL—and possibly a particular revision—of a
- versioned resource. In Subversion, you declare externals
+ versioned object. In Subversion, you declare externals
definitions in groups using the <literal>svn:externals</literal>
property. You can create or modify this property using
<command>svn propset</command> or <command>svn
@@ -3467,31 +3476,38 @@
others update their working copies and receive your changes to
the externals definition.</para>
- <para>The <command>svn status</command> command also recognizes
- externals definitions, displaying a status code of
- <literal>X</literal> for the disjoint subdirectories into which
- externals are checked out, and then recursing into those
- subdirectories to display the status of the external items
- themselves.</para>
+ <tip>
+ <para>Because the <literal>svn:externals</literal> property has
+ a multiline value, we strongly recommend that you use
+ <command>svn propedit</command> instead of <command>svn
+ propset</command>.</para>
+ </tip>
<tip>
<para>You should strongly consider using explicit revision
numbers in all of your externals definitions. Doing so means
that you get to decide when to pull down a different snapshot
of external information, and exactly which snapshot to pull.
- Besides the common sense aspect of not being surprised by
- changes to third-party repositories that you might not have
- any control over, using explicit revision numbers also means
- that as you backdate your working copy to a previous
- revision, your externals definitions will also revert to the
- way they looked in that previous revision, which in turn means
- that the external working copies will be updated to match they
- way <emphasis>they</emphasis> looked back when your repository was
+ Besides avoiding the surprise of getting changes to
+ third-party repositories that you might not have any control
+ over, using explicit revision numbers also means that as you
+ backdate your working copy to a previous revision, your
+ externals definitions will also revert to the way they looked
+ in that previous revision, which in turn means that the
+ external working copies will be updated to match they way
+ <emphasis>they</emphasis> looked back when your repository was
at that previous revision. For software projects, this could
be the difference between a successful and a failed build of
- an older snapshot of your complex codebase.</para>
+ an older snapshot of your complex codebase.</para>
</tip>
+ <para>The <command>svn status</command> command also recognizes
+ externals definitions, displaying a status code of
+ <literal>X</literal> for the disjoint subdirectories into which
+ externals are checked out, and then recursing into those
+ subdirectories to display the status of the external items
+ themselves.</para>
+
<para>The support that exists for externals definitions in
Subversion today can be a little misleading, though. First, an
externals definition can only point to directories, not files.
@@ -3513,17 +3529,54 @@
not affect what gets checked out as an external (though the
relative local target subdirectory will, of course, move with
renamed directory). This can be confusing—even
- frustrating—in certain situations. For example, if you
- use externals definitions on a directory in your
- <filename>/trunk</filename> development line which point to
- other areas of that same line, and then you use <command>svn
- copy</command> to branch that line to some new location
- <filename>/branches/my-branch</filename>, the externals
- definitions on items in your new branch will still refer to
- versioned resources in <filename>/trunk</filename>. Be aware,
- too, that if you need to re-parent your working copy (using
- <command>svn switch --relocate</command>), externals definitions
- will <emphasis>not</emphasis> also be re-parented.</para>
+ frustrating—in certain situations. For example, say you
+ have a top-level directory named
+ <filename>my-project</filename>, and you've created an externals
+ definition on one of its subdirectories
+ (<filename>my-project/some-dir</filename>) which tracks the
+ latest revision of another of its subdirectories
+ (<filename>my-project/external-dir</filename>).</para>
+
+ <screen>
+$ svn co http://svn.example.com/projects .
+A my-project
+A my-project/some-dir
+A my-project/external-dir
+…
+Fetching external item into 'my-project/some-dir/subdir'
+Checked out external at revision 11.
+
+Checked out revision 11.
+$ svn pget svn:externals my-project/some-dir
+subdir http://svn.example.com/projects/my-project/external-dir
+
+$
+</screen>
+
+ <para>Now you use <command>svn move</command> to rename the
+ <filename>my-project</filename> directory. At this point, your
+ externals definition will still refer to a path under the
+ <filename>my-project</filename> directory, even though that
+ directory no longer exists.</para>
+
+ <screen>
+$ svn mv -q my-project renamed-project
+$ svn ci -m "Rename my-project to renamed-project."
+Deleting my-project
+Adding my-renamed-project
+
+Committed revision 12.
+$ svn up
+
+Fetching external item into 'renamed-project/some-dir/subdir'
+svn: Target path does not exist
+$
+</screen>
+
+ <para>Be aware, too, that if you need to re-parent your working
+ copy (using <command>svn switch --relocate</command>), externals
+ definitions will <emphasis>not</emphasis> also be
+ re-parented.</para>
<para>Finally, there might be times when you would prefer that
<command>svn</command> subcommands would not recognize or
Modified: trunk/src/nb/book/ch-fundamental-concepts.xml
==============================================================================
--- trunk/src/nb/book/ch-fundamental-concepts.xml (original)
+++ trunk/src/nb/book/ch-fundamental-concepts.xml Fri Jun 22 08:28:22 2007
@@ -714,15 +714,16 @@
<!-- @ENGLISH {{{
<para>In the second syntax, you need to quote the URL so that the
vertical bar character is not interpreted as a pipe. Also, note
- that a URL uses ordinary slashes even though the native
+ that a URL uses forward slashes even though the native
(non-URL) form of a path on Windows uses backslashes.</para>
@ENGLISH }}} -->
<para>I den andre syntaksen må du sette URLen i hermetegn
(<literal>""</literal>) så det vertikale stolpetegnet ikke blir
tolket som et rør.
- Legg også merke til at en URL bruker vanlige skråstreker selv om
- den lokale (ikke-URL) formen i en sti i MS Windows bruker
- omvendte skråstreker.</para>
+ Legg også merke til at en URL bruker vanlige skråstreker
+ (<literal>/</literal>) selv om den lokale (ikke-URL) formen i en
+ sti i MS Windows bruker omvendte skråstreker
+ (<literal>\</literal>).</para>
<!-- @ENGLISH {{{
<para>Finally, it should be noted that the Subversion client will
More information about the svnbook-dev
mailing list