[svnbook commit] r2640 - branches/fitz-ripping-up-ch-02/src/en/book
fitz
noreply at red-bean.com
Fri Feb 2 03:12:08 CST 2007
Author: fitz
Date: Fri Feb 2 03:12:08 2007
New Revision: 2640
Modified:
branches/fitz-ripping-up-ch-02/src/en/book/app-quickstart.xml
branches/fitz-ripping-up-ch-02/src/en/book/app-svn-for-cvs-users.xml
branches/fitz-ripping-up-ch-02/src/en/book/ch-advanced-topics.xml
branches/fitz-ripping-up-ch-02/src/en/book/ch-basic-usage.xml
branches/fitz-ripping-up-ch-02/src/en/book/ch-reference.xml
branches/fitz-ripping-up-ch-02/src/en/book/ch-repository-admin.xml
Log:
Broad strokes at fleshing out chapter two to the new outline. 95% of
the way to content complete, then I'll start making refining passes.
*** This should build without errors ***
* src/en/book/ch-basic-usage.xml: Almost content complete (but not
reviewed for coherence or clarity).
* src/en/book/ch-reference.xml, src/en/book/ch-advanced-topics.xml,
src/en/book/ch-repository-admin.xml,
src/en/book/app-svn-for-cvs-users.xml,
src/en/book/app-quickstart.xml: Update xrefs
Modified: branches/fitz-ripping-up-ch-02/src/en/book/app-quickstart.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/app-quickstart.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/app-quickstart.xml Fri Feb 2 03:12:08 2007
@@ -187,7 +187,7 @@
<para>Once you have your tree of data ready to go, import it into
the repository with the <command>svn import</command> command
- (see <xref linkend="svn.tour.other.import"/>):</para>
+ (see <xref linkend="svn.tour.importing"/>):</para>
<screen>
$ svn import /tmp/myproject file:///path/to/repos/myproject -m "initial import"
Modified: branches/fitz-ripping-up-ch-02/src/en/book/app-svn-for-cvs-users.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/app-svn-for-cvs-users.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/app-svn-for-cvs-users.xml Fri Feb 2 03:12:08 2007
@@ -162,7 +162,7 @@
<term><command>svn revert</command></term>
<listitem>
<para>Removes your local changes (see <xref
- linkend="svn.tour.cycle.examine.revert"/>)</para>
+ linkend="svn.tour.cycle.revert"/>)</para>
</listitem>
</varlistentry>
Modified: branches/fitz-ripping-up-ch-02/src/en/book/ch-advanced-topics.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/ch-advanced-topics.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/ch-advanced-topics.xml Fri Feb 2 03:12:08 2007
@@ -33,7 +33,7 @@
<sect1 id="svn.tour.revs.specifiers">
<title>Revision Specifiers</title>
- <para>As you saw in <xref linkend="svn.tour.revs" />, revision
+ <para>As you saw in <xref linkend="svn.basic.in-action.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
@@ -1771,7 +1771,7 @@
<computeroutput>L</computeroutput> in the third column of
<command>svn status</command> output, and removed by the
<command>svn cleanup</command> command, as described in <xref
- linkend="svn.tour.other.cleanup"/>.</para>
+ linkend="svn.tour.cleanup"/>.</para>
<para>Secondly, there are <firstterm>database locks</firstterm>,
used internally by the Berkeley DB backend to prevent clashes
Modified: branches/fitz-ripping-up-ch-02/src/en/book/ch-basic-usage.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/ch-basic-usage.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/ch-basic-usage.xml Fri Feb 2 03:12:08 2007
@@ -4,11 +4,12 @@
<para>Now we will go into the details of using Subversion. By the
time you reach the end of this chapter, you will be able to
perform almost all the tasks you need to use Subversion in a
- normal day's work. TODO:fix You'll start with an initial checkout of
- your code, and walk through making changes and examining those
- changes. You'll also see how to bring changes made by others
- into your working copy, examine them, and work through any
- conflicts that might arise.</para>
+ normal day's work. You'll start with getting your files into
+ Subversion, followed by an initial checkout of your code. We'll
+ then walk you through making changes and examining those changes.
+ You'll also see how to bring changes made by others into your
+ working copy, examine them, and work through any conflicts that
+ might arise.</para>
<para>Note that this chapter is not meant to be an exhaustive list
of all Subversion's commands—rather, it's a conversational
@@ -25,7 +26,6 @@
<sect1 id="svn.tour.help">
<title>Help!</title>
-
<para>Before reading on, here is the most important command you'll
ever need when using Subversion: <command>svn help</command>.
The Subversion command-line client is
@@ -38,46 +38,24 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
- <sect1 id="svn.tour.import">
+ <sect1 id="svn.tour.importing">
<title>Getting Data into your Repository</title>
- There are several different ways to get data into your Subversion
- repository. There's svn import, which is usually used if you want
- to put an existing tree of files into your repository as a unique
- project, but if you already have a working copy, svn add followed
- by svn commit will basically do the same thing.
-
- svn import:
- - Doesn't require a working copy
- - Immediate commit
- - Usually used to place new projects into Subversion
-
- svn add && svn commit:
- - Requires a working copy
- - Usually used to augment projects already in Subversion
- - Requires a separate commit step
- - Can be reverted without touching the repository
-
- TODO: recommended layout
-
- TODO: talk about import in depth? Check notes.
-
-TODO: zap this
- <para>You use <command>svn import</command> to import a new
- project into a Subversion repository. While this is most likely
- the very first thing you will do when you set up your Subversion
- server, it's not something that happens very often. For a
- detailed description of import, see <xref
- linkend="svn.tour.other.import"/> later in this chapter.</para>
-
+ <para>There are two ways to get new files into your Subversion
+ repository: <command>svn import</command> and <command>svn
+ add</command>.</para>
<!-- =============================================================== -->
- <sect2 id="svn.tour.other.import">
- <title><command>svn import</command></title>
+ <sect2 id="svn.tour.importing.import">
+ <title>svn import</title>
- <para>The <command>svn import</command> command is a quick way
- to copy an unversioned tree of files into a repository,
- creating intermediate directories as necessary.</para>
+ <para>The <command>svn import</command> command is a quick way to
+ copy an unversioned tree of files into a repository, creating
+ intermediate directories as necessary. <command>svn
+ import</command> doesn't require a working copy, and your files
+ are immediately committed to the repository. This is typically
+ used when you have an existing tree of files that you want to
+ begin tracking in your Subversion repository. For example:</para>
<screen>
$ svnadmin create /usr/local/svn/newrepos
@@ -87,6 +65,7 @@
Adding mytree/bar.c
Adding mytree/subdir
Adding mytree/subdir/quux.h
+
Committed revision 1.
</screen>
@@ -108,11 +87,75 @@
</sect2>
+ <!-- =============================================================== -->
+ <sect2 id="svn.tour.importing.add">
+ <title>svn add</title>
+ <para><command>svn add</command> on the other hand requires a
+ working copy and merely schedules the added files for addition
+ in your working copy. <command>svn add</command> doesn't
+ contact the repository in any way, nor does it commit the files,
+ which means that you can continue to make changes to them (or
+ even <command>svn revert</command> them) before committing your
+ changes. This is especially useful if the unversioned files
+ you're adding are part of a logical change that you're making to
+ files that are already in your working copy:</para>
+ <screen>
+$ svn st
+M Makefile
+$ svn add mytree
+A mytree
+A mytree/bar.c
+A mytree/foo.c
+A mytree/subdir
+A mytree/subdir/quux.h
+</screen>
+ <para>We've added our new tree to our working copy which already
+ has a modified file in it. Now we're ready to commit our
+ changes:</para>
+ <screen>
+$ svn commit -m "Adding new tree to existing working copy with a local change"
+Adding mytree
+Adding mytree/bar.c
+Adding mytree/foo.c
+Adding mytree/subdir
+Adding mytree/subdir/quux.h
+Sending Makefile
+Transmitting file data ...
+Committed revision 17.
+</screen>
+
+ </sect2>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.tour.importing.layout">
+ <title>Recommended repository layout</title>
+
+ <para>While Subversion's flexibility allows you to layout your
+ repository in any way that you choose, we recommend that you
+ create a <filename>trunk</filename> directory to hold the
+ <quote>main line</quote> of development, a
+ <filename>branches</filename> directory to contain branch
+ copies, and a <filename>tags</filename> directory to contain tag
+ copies:</para>
+
+ <screen>
+$ svn list file:///usr/local/svn/repos
+/trunk
+/branches
+/tags
+</screen>
+
+ <para>For details and how to setup multiple projects, see <xfer
+ linkend="svn.branchmerge.maint.layout"/> and <xref
+ linkend="svn.reposadmin.projects.chooselayout"/> to read more
+ about <quote>project roots</quote></para>
+
+ </sect2>
</sect1>
@@ -272,19 +315,42 @@
<sect2 id="svn.tour.initial.disabling-password-caching">
<title>Disabling Password Caching</title>
- <para>TODO:write this</para>
+ <para>When you perform a Subversion operation that requires you
+ to authenticate, by default Subversion caches your
+ authentication credentials on disk. If you're concerned about
+ caching your Subversion passwords,<footnote><para>Of course,
+ you're not terribly worried because a)you know that you can't
+ <emphasis>really</emphasis> delete anything from Subversion
+ and b)your Subversion password isn't the same as any of the
+ other three million passwords you have, right?
+ Right?</para></footnote> you can disable caching either
+ permanently or on a case-by-case basis.</para>
+
+ <para>To disable password caching for a particular one-time
+ command, pass the <option >--no-auth-cache</option > option on
+ the commandline. To permanently disable caching, you can add
+ the line <literal>store-passwords = no</literal> to your local
+ machine's Subversion configuration file. See <xref
+ linkend="svn.serverconfig.netmodel.credcache"/> for
+ details.</para>
</sect2>
-
<sect2 id="svn.tour.initial.different-user">
<title>Authenticating as a Different User</title>
- <para>TODO:write this</para>
+ <para>Since Subversion caches auth credentials by default (both
+ username and password), it conveniently remembers who you were
+ acting as the last time you modified you working copy. But
+ sometimes that's not helpful—particularly if you're
+ working in a shared working copy, like a system configuration
+ directory or a webserver document root. In this case, just
+ pass the <option>--username option</option > on the
+ commandline and Subversion will attempt to authenticate as
+ that user, prompting you for a password if necessary.</para>
</sect2>
-
</sect1>
<!-- ================================================================= -->
@@ -332,11 +398,6 @@
<listitem>
<para>Examine your changes</para>
-
-TODO: See an overview of your changes
-TODO: See the details of your local modifications
-
-
<itemizedlist>
<listitem>
<para><command>svn status</command></para>
@@ -347,15 +408,18 @@
</itemizedlist>
</listitem>
-TODO: Undoing working changes
-
<listitem>
- <para>Resolving Conflicts (Merging Others' Changes)</para>
+ <para>Possibly undo some changes</para>
+ <itemizedlist>
+ <listitem>
+ <para><command>svn revert</command></para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
-TODO: Merging Conflicts by Hand
-TODO: Copying a File Onto Your Working File
-TODO: Punting: aborting your changes
+ <listitem>
+ <para>Resolving Conflicts (Merging Others' Changes)</para>
<itemizedlist>
<listitem>
<para><command>svn update</command></para>
@@ -363,9 +427,6 @@
<listitem>
<para><command>svn resolved</command></para>
</listitem>
- <listitem>
- <para><command>svn revert</command></para>
- </listitem>
</itemizedlist>
</listitem>
@@ -677,33 +738,24 @@
<para>Once you've finished making changes, you need to commit
them to the repository, but before you do so, it's usually a
good idea to take a look at exactly what you've changed. By
- examining your changes before you commit, you can make a
- more accurate log message. You may also discover that
- you've inadvertently changed a file, and this gives you a
- chance to revert those changes before committing.
- Additionally, this is a good opportunity to review and
- scrutinize changes before publishing them. You can see
- exactly what changes you've made by using <command>svn
- status</command>, <command>svn diff</command>, and
- <command>svn revert</command>. You will usually use the first
- two commands to find out what files have changed in your
- working copy, and then perhaps the third to revert some (or
- all) of those changes.</para>
-
- <!-- pll - Fri 07 Feb 2003 12:55:07 -->
- <!-- I find this following paragraph a little unclear. Mostly for -->
- <!-- the same reasons as I found the sidebar above unclear. There -->
- <!-- hasn't been much discussion of the Subversion architecture, and -->
- <!-- therefore, nothing has been clearly stated wrt the fact that the -->
- <!-- repository may not be local. -->
-
+ examining your changes before you commit, you can make a more
+ accurate log message. You may also discover that you've
+ inadvertently changed a file, and this gives you a chance to
+ revert those changes before committing. Additionally, this is
+ a good opportunity to review and scrutinize changes before
+ publishing them. You can see an overview of the changes
+ you've made by using <command>svn status</command>, and dig
+ into the details of those changes by using <command>svn
+ diff</command>.</para>
+
<sidebar>
<title>Look Ma! No Network!</title>
<para>All three of these commands (<command>svn
status</command>, <command>svn diff</command>, and
<command>svn revert</command>) can be used without any
- network access. This makes it easy to manage your
+ network access (assuming, of course, that you're not using a
+ local repository). This makes it easy to manage your
changes-in-progress when you are somewhere without a network
connection, such as travelling on an airplane, riding a
commuter train or hacking on the beach.</para>
@@ -735,10 +787,12 @@
changes without contacting the repository.</para>
<sect3 id="svn.tour.cycle.examine.status">
- <title><command>svn status</command></title>
+ <title>See an overview of your changes</title>
- <para>You'll probably use the <command>svn status</command>
- command more than any other Subversion command.</para>
+ <para>To get an overview of your changes, you'll use the
+ <command>svn status</command> command. You'll probably use
+ <command>svn status</command> more than any other Subversion
+ command.</para>
<sidebar>
<title>CVS Users: Hold That Update!</title>
@@ -754,9 +808,9 @@
<para>In Subversion, <command>update</command> does just
that—it updates your working copy with any changes
committed to the repository since the last time you've
- updated your working copy. You'll have to break the habit
- of using the <command>update</command> command to see what
- local modifications you've made.</para>
+ updated your working copy. You may have to break the
+ habit of using the <command>update</command> command to
+ see what local modifications you've made.</para>
</sidebar>
@@ -793,12 +847,11 @@
</screen>
<para>In this output format <command>svn status</command>
- prints five columns of characters, followed by several
+ prints six columns of characters, followed by several
whitespace characters, followed by a file or directory name.
The first column tells the status of a file or directory
and/or its contents. The codes printed here are:</para>
-
<variablelist>
<varlistentry>
@@ -1048,7 +1101,7 @@
</sect3>
<sect3 id="svn.tour.cycle.examine.diff">
- <title><command>svn diff</command></title>
+ <title>Examine the details of your local modifications</title>
<para>Another way to examine your changes is with the
<command>svn diff</command> command. You can find out
@@ -1060,7 +1113,7 @@
you want diff output in a different format, specify an
external diff program using <option>--diff-cmd</option> and
pass any flags you'd like to it using the
- <option>--extensions</option> switch. For example, to see
+ <option>--extensions</option> option. For example, to see
local differences in file <filename>foo.c</filename> in
context output format while ignoring whitespace changes, you
might run <command>svn diff --diff-cmd /usr/bin/diff
@@ -1134,31 +1187,35 @@
</sect3>
- <sect3 id="svn.tour.cycle.examine.revert">
- <title><command>svn revert</command></title>
+ </sect2>
- <para>Now suppose you see the above diff output, and realize
- that your changes to <filename>README</filename> are a
- mistake; perhaps you accidentally typed that text into the
- wrong file in your editor.</para>
-
- <para>This is a perfect opportunity to use <command>svn
- revert</command>.</para>
-
- <screen>
+
+ <!-- =============================================================== -->
+ <sect2 id="svn.tour.cycle.revert">
+ <title>Undoing Working Changes</title>
+
+ <para>Now suppose you see the above diff output, and realize
+ that your changes to <filename>README</filename> are a
+ mistake; perhaps you accidentally typed that text into the
+ wrong file in your editor.</para>
+
+ <para>This is a perfect opportunity to use <command>svn
+ revert</command>:</para>
+
+ <screen>
$ svn revert README
Reverted 'README'
</screen>
- <para>Subversion reverts the file to its pre-modified state by
- overwriting it with the cached <quote>pristine</quote> copy
- from the <filename>.svn</filename> area. But also note that
- <command>svn revert</command> can undo
- <emphasis>any</emphasis> scheduled operations—for
- example, you might decide that you don't want to add a new
- file after all:</para>
+ <para>Subversion reverts the file to its pre-modified state by
+ overwriting it with the cached <quote>pristine</quote> copy
+ from the <filename>.svn</filename> area. But also note that
+ <command>svn revert</command> can undo
+ <emphasis>any</emphasis> scheduled operations—for
+ example, you might decide that you don't want to add a new
+ file after all:</para>
- <screen>
+ <screen>
$ svn status foo
? foo
@@ -1172,22 +1229,22 @@
? foo
</screen>
- <note>
- <para><command>svn revert</command>
- <replaceable>ITEM</replaceable> has exactly the same
- effect as deleting <replaceable>ITEM</replaceable> from
- your working copy and then running <command>svn update -r
- BASE</command> <replaceable>ITEM</replaceable>. However,
- if you're reverting a file, <command>svn revert</command>
- has one very noticeable difference—it doesn't have
- to communicate with the repository to restore your
- file.</para>
- </note>
+ <note>
+ <para><command>svn revert</command>
+ <replaceable>ITEM</replaceable> has exactly the same
+ effect as deleting <replaceable>ITEM</replaceable> from
+ your working copy and then running <command>svn update -r
+ BASE</command> <replaceable>ITEM</replaceable>. However,
+ if you're reverting a file, <command>svn revert</command>
+ has one very noticeable difference—it doesn't have
+ to communicate with the repository to restore your
+ file.</para>
+ </note>
- <para>Or perhaps you mistakenly removed a file from version
- control:</para>
+ <para>Or perhaps you mistakenly removed a file from version
+ control:</para>
- <screen>
+ <screen>
$ svn status README
README
@@ -1201,8 +1258,6 @@
README
</screen>
- </sect3>
-
</sect2>
<!-- =============================================================== -->
@@ -1262,8 +1317,8 @@
</listitem>
<listitem>
- <para>For every conflicted file, Subversion places up to
- three extra unversioned files in your working copy:</para>
+ <para>For every conflicted file, Subversion places three
+ extra unversioned files in your working copy:</para>
<variablelist>
@@ -1634,71 +1689,6 @@
However, sometimes you just want to <emphasis>peer
into</emphasis> the past instead of <emphasis>going
into</emphasis> the past.</para>
-
-
-
- <!-- =============================================================== -->
- <sect2 id="todo">
- <title>Generating a list of historical changes</title>
-
- <para>todo</para>
- </sect2>
-
-
- <!-- =============================================================== -->
- <sect2 id="todo">
- <title>Examining the details of historical changes</title>
-
- <para>todo</para>
- </sect2>
-
-
-
- <sect3 id="todo">
- <title>Examining Local Changes</title>
-
- <para>todo</para>
- </sect3>
-
-
- <sect3 id="todo">
- <title>Comparing Working Copy to Repository</title>
-
- <para>todo</para>
- </sect3>
-
-
- <sect3 id="todo">
- <title>Comparing Repository to Repository</title>
-
- <para>todo</para>
- </sect3>
-
-
-
- <!-- =============================================================== -->
- <sect2 id="todo">
- <title>Browsing the repository (was 'svn cat' and 'svn list')</title>
-
- <para>todo</para>
- </sect2>
-
-
- <!-- =============================================================== -->
- <sect2 id="todo">
- <title>Fetching older repository snapshots (co, export, update)</title>
-
- <para>todo</para>
- </sect2>
-
-
-
-
-
-
-
-
-
<para>There are several commands that can provide you with
historical data from the repository:</para>
@@ -1744,7 +1734,7 @@
<!-- =============================================================== -->
<sect2 id="svn.tour.history.log">
- <title><command>svn log</command></title>
+ <title>Generating a list of historical changes</title>
<para>To find information about the history of a file or
directory, use the <command>svn log</command>
@@ -1861,7 +1851,7 @@
<!-- =============================================================== -->
<sect2 id="svn.tour.history.diff">
- <title><command>svn diff</command></title>
+ <title>Examining the details of historical changes</title>
<para>We've already seen <command>svn diff</command>
before—it displays file differences in unified diff
@@ -1982,14 +1972,24 @@
</sect2>
<!-- =============================================================== -->
- <sect2 id="svn.tour.history.cat">
- <title><command>svn cat</command></title>
+ <sect2 id="svn.tour.history.browsing">
+ <title>Browsing the repository</title>
- <para>If you want to examine an earlier version of a file and
- not necessarily the differences between two files, you can use
- <command>svn cat</command>:</para>
+ <para>Using <command>svn cat</command> and <command>svn
+ list</command>, you can view various revisions of files and
+ directories without changing the working revision of your
+ working copy. In fact, you don't even need a working copy to
+ use either one.</para>
+
+ <sect3 id="svn.tour.history.browsing.cat">
+ <title><command>svn cat</command></title>
+
+
+ <para>If you want to examine an earlier version of a file and
+ not necessarily the differences between two files, you can use
+ <command>svn cat</command>:</para>
- <screen>
+ <screen>
$ svn cat --revision 2 rules.txt
Be kind to others
Freedom = Chocolate Ice Cream
@@ -1998,42 +1998,41 @@
$
</screen>
- <para>You can also redirect the output directly into a
- file:</para>
+ <para>You can also redirect the output directly into a
+ file:</para>
- <screen>
+ <screen>
$ svn cat --revision 2 rules.txt > rules.txt.v2
$
</screen>
- <para>You're probably wondering why we don't just use
- <command>svn update --revision</command> to update the file to
- the older revision. There are a few reasons why we might
- prefer to use <command>svn cat</command>.</para>
-
- <para>First, you may want to see the differences between two
- revisions of a file using an external diff program (perhaps a
- graphical one, or perhaps your file is in such a format that
- the output of unified diff is nonsensical). In this case,
- you'll need to grab a copy of the old revision, redirect it to
- a file, and pass both that and the file in your working copy
- to your external diff program.</para>
-
- <para>Secondly, it's sometimes just easier to look at an older
- version of a file in its entirety than to look only at the
- differences between it and another revision.</para>
-
- </sect2>
-
- <!-- =============================================================== -->
- <sect2 id="svn.tour.history.list">
- <title><command>svn list</command></title>
-
- <para>The <command>svn list</command> command shows you what
- files are in a repository directory without actually
- downloading the files to your local machine:</para>
-
- <screen>
+ <para>You're probably wondering why we don't just use
+ <command>svn update --revision</command> to update the file to
+ the older revision. There are a few reasons why we might
+ prefer to use <command>svn cat</command>.</para>
+
+ <para>First, you may want to see the differences between two
+ revisions of a file using an external diff program (perhaps a
+ graphical one, or perhaps your file is in such a format that
+ the output of unified diff is nonsensical). In this case,
+ you'll need to grab a copy of the old revision, redirect it to
+ a file, and pass both that and the file in your working copy
+ to your external diff program.</para>
+
+ <para>Secondly, it's sometimes just easier to look at an older
+ version of a file in its entirety than to look only at the
+ differences between it and another revision.</para>
+
+ </sect3>
+
+ <sect3 id="svn.tour.history.browsing.list">
+ <title><command>svn list</command></title>
+
+ <para>The <command>svn list</command> command shows you what
+ files are in a repository directory without actually
+ downloading the files to your local machine:</para>
+
+ <screen>
$ svn list http://svn.collab.net/repos/svn
README
branches/
@@ -2042,11 +2041,11 @@
trunk/
</screen>
- <para>If you want a more detailed listing, pass the
- <option>--verbose</option> (<option>-v</option>) flag to get
- output like this:</para>
+ <para>If you want a more detailed listing, pass the
+ <option>--verbose</option> (<option>-v</option>) flag to get
+ output like this:</para>
- <screen>
+ <screen>
$ svn list --verbose http://svn.collab.net/repos/svn
2755 harry 1331 Jul 28 02:07 README
2773 sally Jul 29 15:07 branches/
@@ -2055,17 +2054,29 @@
2785 sally Jul 29 19:07 trunk/
</screen>
- <para>The columns tell you the revision at which the file or
- directory was last modified, the user who modified it, the size
- if it is a file, the date it was last modified, and the item's
- name.</para>
-
+ <para>The columns tell you the revision at which the file or
+ directory was last modified, the user who modified it, the size
+ if it is a file, the date it was last modified, and the item's
+ name.</para>
+
+ </sect3>
+
</sect2>
<!-- =============================================================== -->
<sect2 id="svn.tour.history.finalword">
<title>A Final Word on History</title>
+
+
+
+ <para>
+ Fetching older repository snapshots...
+TODO: co
+TODO: export
+TODO: update
+</para>
+
<para>In addition to all of the above commands, you can use
<command>svn update</command> and <command>svn
checkout</command> with the <option>--revision</option> switch
@@ -2088,42 +2099,34 @@
<!-- ================================================================= -->
<!-- ================================================================= -->
<!-- ================================================================= -->
- <sect1 id="svn.tour.other">
- <title>Other Useful Commands</title>
+ <sect1 id="svn.tour.cleanup">
+ <title>Sometimes You Just Need to Cleanup</title>
- <para>While not as frequently used as the commands previously
- discussed in this chapter, you will occasionally need these
- commands.</para>
+ <para>When Subversion modifies your working copy (or any
+ information within <filename>.svn</filename>), it tries to do
+ so as safely as possible. Before changing the working copy,
+ Subversion writes its intentions to a log file. Next it
+ executes the commands in the log file to apply the requested
+ change, holding a lock on the relevant part of the working
+ copy while it works — to prevent other Subversion clients
+ from accessing the working copy in mid-change. Finally,
+ Subversion removes the log file. Architecturally, this is
+ similar to a journaled filesystem. If a Subversion operation
+ is interrupted (if the process is killed, or if the machine
+ crashes, for example), the log files remain on disk. By
+ re-executing the log files, Subversion can complete the
+ previously started operation, and your working copy can get
+ itself back into a consistent state.</para>
+
+ <para>And this is exactly what <command>svn cleanup</command>
+ does: it searches your working copy and runs any leftover
+ logs, removing working copy locks in the process.
+ If Subversion ever tells you that some part of your working copy
+ is <quote>locked</quote>, then this is the command that you
+ should run. Also, <command>svn status</command> will display
+ an <literal>L</literal> next to locked items:</para>
- <!-- =============================================================== -->
- <sect2 id="svn.tour.other.cleanup">
- <title><command>svn cleanup</command></title>
-
- <para>When Subversion modifies your working copy (or any
- information within <filename>.svn</filename>), it tries to do
- so as safely as possible. Before changing the working copy,
- Subversion writes its intentions to a log file. Next it
- executes the commands in the log file to apply the requested
- change, holding a lock on the relevant part of the working
- copy while it works — to prevent other Subversion clients
- from accessing the working copy in mid-change. Finally,
- Subversion removes the log file. Architecturally, this is
- similar to a journaled filesystem. If a Subversion operation
- is interrupted (if the process is killed, or if the machine
- crashes, for example), the log files remain on disk. By
- re-executing the log files, Subversion can complete the
- previously started operation, and your working copy can get
- itself back into a consistent state.</para>
-
- <para>And this is exactly what <command>svn cleanup</command>
- does: it searches your working copy and runs any leftover
- logs, removing working copy locks in the process.
- If Subversion ever tells you that some part of your working copy
- is <quote>locked</quote>, then this is the command that you
- should run. Also, <command>svn status</command> will display
- an <literal>L</literal> next to locked items:</para>
-
- <screen>
+ <screen>
$ svn status
L somedir
M somedir/foo.c
@@ -2133,16 +2136,12 @@
M somedir/foo.c
</screen>
- <para>Don't confuse these working copy locks with the ordinary
- locks that Subversion users create when using
- the <quote>lock-modify-unlock</quote> model of concurrent
- version control; see
- <xref linkend="svn.advanced.locking.meanings"/> for
- clarification.</para>
-
- </sect2>
-
-
+ <para>Don't confuse these working copy locks with the ordinary
+ locks that Subversion users create when using
+ the <quote>lock-modify-unlock</quote> model of concurrent
+ version control; see
+ <xref linkend="svn.advanced.locking.meanings"/> for
+ clarification.</para>
</sect1>
Modified: branches/fitz-ripping-up-ch-02/src/en/book/ch-reference.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/ch-reference.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/ch-reference.xml Fri Feb 2 03:12:08 2007
@@ -2219,7 +2219,7 @@
</screen>
<para>For further details, see <xref
- linkend="svn.tour.history.list"/>.</para>
+ linkend="svn.tour.history.browsing.list"/>.</para>
</refsect1>
</refentry>
@@ -3705,7 +3705,7 @@
<para>The third column is populated only if the
working copy directory is locked. (See
- <xref linkend="svn.tour.other.cleanup"/>.)</para>
+ <xref linkend="svn.tour.cleanup"/>.)</para>
<variablelist>
@@ -4234,7 +4234,7 @@
<option>--revision</option> switch. As part of the
synchronization, <command>svn update</command> also
removes any stale locks (see <xref
- linkend="svn.tour.other.cleanup"/>) found in the
+ linkend="svn.tour.cleanup"/>) found in the
working copy.</para>
<para>For each updated item a line will start with a
Modified: branches/fitz-ripping-up-ch-02/src/en/book/ch-repository-admin.xml
==============================================================================
--- branches/fitz-ripping-up-ch-02/src/en/book/ch-repository-admin.xml (original)
+++ branches/fitz-ripping-up-ch-02/src/en/book/ch-repository-admin.xml Fri Feb 2 03:12:08 2007
@@ -2762,7 +2762,7 @@
skeletal repository layout, one-by-one. A quicker way to
accomplish the same task is to use the <command>svn
import</command> command (see <xref
- linkend="svn.tour.other.import"/>). By first creating the layout
+ linkend="svn.tour.importing"/>). By first creating the layout
in a temporary location on your drive, you can import the
whole layout tree into the repository in a single
commit:</para>
More information about the svnbook-dev
mailing list