In an attempt to play catch-up, I read the handbook, which is
rather good. While I was going through it, I was noticing a few things,
and I figured that it would be a good idea to edit-as-I go so I can
catch all the things you catch on a first read as a newbie and don't
catch when you are scanning for references. So I made a patch.
Edits can be subjective, so, well there you go. No real content
changes, just tweaks to help me read it more easily. There were a few
common sorts of tweaks:
There is a tendency to describe technical things with other technical
things. Like saying meta-data is stored in a hash table. Try to use
layspeak a bit more.
There is a lot of ``quoted'' terminology here. It's apologetic, and
English teachers beat that out of me when I was younger. If
describing a new term, use @dfn{}. If calling something pristine,
just call it pristine. It's a real word, just use it.
Use the long form for svn subcommands. The user will figure out the
shortcuts once they know how to use things, but the long forms are
meant to be descriptive, and more appropriate for documentation. Add
a note that short forms exist.
I added two ## CLARIFY notes where I didn't follow what was being
said.
Hope this is useful.
-wsv
Index: ./doc/handbook/getting_started.texi
===================================================================
--- ./doc/handbook/getting_started.texi
+++ ./doc/handbook/.svn/tmp/getting_started.texi.62480.00001.tmp
Thu Aug 15 09:51:02 2002
@@ -39,7 +39,7 @@
Subversion aims to be the successor to CVS
(@uref{http://www.cvshome.org/}).
-At the time of writing, CVS is the standard Free revision control
system
+At the time of writing, CVS is the standard free revision control
system
used by the open-source community. It has a hard-earned, well-deserved
reputation as stable and useful software, and has a design that makes
it
perfect for open-source development. However, it also has a number of
@@ -53,10 +53,10 @@
be written such that any CVS user should be able to start using it with
little effort.
-Collabnet (@uref{http://www.collab.net/}) provided the initial funding
+CollabNet (@uref{http://www.collab.net/}) provided the initial funding
in 2000 to begin development work, and the effort has now blossomed
-into a large, open-source project backed by a community of free
-software developers.
+into a large, open-source project backed by a community of software
+developers, documentation writers, and users.
@subsection Audience
@@ -64,7 +64,7 @@
The intended audience of this book is anyone who has used a revision
control system before, although perhaps not Subversion or CVS. It
assumes that the reader is computer-literate, and reasonably
-comfortable at a Unix command-line.
+comfortable using a Unix command-line.
People familiar with CVS may want to skip some of the introductory
sections that describe Subversion's concurrent versioning model.
@@ -87,13 +87,13 @@
client-side `move' and `copy' commands.
@item
-@b{Atomic commits} A commit either goes into the repository
-completely, or not all.
+@b{Atomic commits} A commit (changes to a set of files) is either
+recorded in the repository completely, or not all.
@item
@b{Advanced network layer} The Subversion network server is Apache,
-and client and server speak WebDAV protocol to one another. (see
-@ref{Design})
+and the client and server speak the WebDAV protocol to one another.
+(see @ref{Design})
@item
@b{Faster network access} A binary diffing algorithm is used to store
@@ -101,17 +101,17 @@
is of text or binary type.
@item
-@b{Meta-data} Each file or directory has an invisible hash table
-attached. You can invent and store any arbitrary key/value pairs you
-wish: owner, perms, icons, app-creator, mime-type, personal notes,
-etc. This is a general-purpose feature for users. Properties are
-versioned over time, just like file contents.
+@b{Meta-data} Each file or directory has a set of attributes
+associated with it. You can invent and store any arbitrary key/value
+pairs you wish: owner, permissions, icons, creator application,
+mime-type, personal notes, etc. This is a general-purpose feature for
+users. Properties are versioned over time, just like file contents.
@item
@b{Hackability} Subversion has no historical baggage; it is primarily
a collection of shared C libraries with well-defined APIs. This makes
-Subversion extremely maintainable and usable by other applications and
-languages.
+Subversion extremely maintainable and usable by other applications in
+a variety of programming languages.
@end itemize
@@ -179,7 +179,7 @@
The Subversion Filesystem is not a kernel-level filesystem that one
would install in an operating system (like the Linux ext2 or NTFS), but
a virtual filesystem. It is implemented as library which exports a C
-API that simulates a filesystem -- specifically, a ``versioned''
+API that simulates a filesystem -- specifically, a @emph{versioned}
filesystem -- but uses a database system for the back-end storage
mechanism.
@@ -204,25 +204,26 @@
Mac OS X, and possibly Netware.
However, Subversion depends on more than just APR -- the Subversion
-"server" is Apache httpd itself. Apache httpd is a time-tested,
-extensible open-source server process that is ready for serious use.
It
-can sustain a high network load, runs on many platforms, and can
operate
-through firewalls. It can use a number of different authentication
-protocols and do network pipelining and caching. By using Apache as a
-server, Subversion gets all these features for free.
+@dfn{server} is the Apache HTTP Server (httpd). Apache httpd is a
+time-tested, extensible open-source server process that is ready for
+serious use. It can sustain a high network load, runs on many
+platforms, and can operate through firewalls. It can use a number of
+different authentication protocols and do network pipelining and
+caching. By extending the Apache HTTP Server, Subversion gets all
+these features for free.
Subversion uses WebDAV as its network protocol. DAV (Distributed
Authoring and Versioning) is a whole discussion in itself (see
@uref{http://www.webdav.org/}) -- but in short, it's an extension to
-HTTP that allows reads/writes and ``versioning'' of files over the web.
-The Subversion project is hoping to ride a slowly rising tide of
+HTTP that allows reads/writes and @dfn{versioning} of files over the
+web. The Subversion project is hoping to ride a slowly rising tide of
support for this protocol: all of the latest file-browsers for Win32,
-MacOS, and GNOME speak this protocol already. Interoperability will
+Mac OS, and GNOME speak this protocol already. Interoperability will
(hopefully) become more and more of a boon over time.
-For users who simply wish to access Subversion repositories on their
-local disk, the client can do this too; no network is required. The
-"Repository Access" layer (RA) is an abstract API implemented by both
+For users who simply wish to access Subversion repositories on
+local disks, the client can do this too; no network is required. The
+@dfn{Repository Access} (RA) layer is an abstract API implemented by
both
the DAV and local-access RA libraries. This is a specific benefit of
writing a ``librarized'' revision control system -- if you feel like
writing a new network protocol for Subversion, just write a new library
@@ -231,7 +232,7 @@
@subsection Client Libraries
-On the client side, the Subversion ``working copy'' library maintains
+On the client side, the Subversion @dfn{working copy} library maintains
administrative information within special .svn subdirectories, similar
in purpose to the CVS administrative directories found in CVS working
copies.
@@ -242,14 +243,14 @@
the current state of the working copy directory (and which basically
serves the purposes of CVS's Entries, Root, and Repository files
combined). But other items present (and not found in CVS) include
-storage locations for the versioned ``properties'' (the metadata
+storage locations for the versioned @dfn{properties} (the metadata
mentioned in ``Subversion Features'' above) and private caches of
pristine versions of each file. This latter feature provides the
ability to report local modifications -- and do reversions --
@emph{without} network access. Authentication data is also stored
within .svn/, rather than in a single .cvspass-like file.
-The Subversion ``client'' library has the broadest responsibility; its
job
+The Subversion @dfn{client} library has the broadest responsibility;
its job
is to mingle the functionality of the working-copy library with that of
the repository-access library, and then to provide a highest-level API
to any application that wishes to perform general revision control
@@ -260,10 +261,9 @@
the working-copy library, which then writes a full working copy to disk
(.svn directories and all.)}
-The client library is designed to be used by any application. While
the
-Subversion source code includes a standard command-line client, it
-should be very easy to write any number of GUI clients on top of the
-client library.
+The client library is designed to be used by any application. While
+Subversion includes a standard command-line client, it should be very
+easy to write any number of GUI clients on top of the client library.
@c ------------------------------------------------------------------
@@ -452,7 +452,7 @@
The initial revision of a freshly created repository is numbered zero,
and consists of an empty root directory.
-Unlike those of many other systems, Subversion's revision numbers apply
+Unlike those of some other systems, Subversion's revision numbers apply
to an entire tree, not individual files. Each revision number selects
an
entire tree.
@@ -522,7 +522,7 @@
@item
@b{Unchanged, and out-of-date}. The file has not been changed in the
working directory, but it has been changed in the repository. The file
-should eventually be updated, to make it current with the public
+should eventually be updated, to make it current with the last
published
revision.
@item
@b{Locally changed, and out-of-date}. The file has been changed both
@@ -573,11 +573,12 @@
@itemize @bullet
@item
changes usually do not conflict, so Subversion's behavior does the
right
-thing by default, while locking can interfere with legitimate work;
+thing in the most common case, while locking can interfere with
+legitimate work;
@item
locking can prevent conflicts within a file, but not conflicts between
files (say, between a C header file and another file that includes it),
-so it doesn't really solve the problem; and finally,
+so it doesn't really solve the problem it is trying to solve; and
finally,
@item
people often forget that they are holding locks, resulting in
unnecessary delays and friction.
@@ -614,7 +615,7 @@
The Subversion client has an abstract interface for accessing a
-repository. Two ``Repository Access'' (RA) implementations currently
+repository. Two @dfn{Repository Access} (RA) implementations currently
exist as libraries. You can see which methods are available to your
svn
client like so:
@@ -674,7 +675,7 @@
@node Make some working copies
@subsubsection Make some working copies
-Now check out a fresh ``working copy'' of your project. To do this, we
+Now check out a fresh working copy of your project. To do this, we
specify a URL to the exact directory within the repository that we
want.
The parameter after the URL allows us to name the working copy we
check out.
@@ -711,7 +712,7 @@
That's a lot of changes! If we were to leave and come back tomorrow,
how could we remember what changes we'd made? Easy. The @samp{status}
-command will show us all of the ``local modifications'' in our working
+command will show us all of the local modifications in our working
copy:
@example
Index: ./doc/handbook/client.texi
===================================================================
--- ./doc/handbook/client.texi
+++ ./doc/handbook/.svn/tmp/client.texi.62480.00001.tmp Thu Aug 15
09:51:02 2002
@@ -39,7 +39,7 @@
repository that you checked out.
@example
-$ svn co http://svn.collab.net/repos/svn/trunk
+$ svn checkout http://svn.collab.net/repos/svn/trunk
A trunk/subversion.dsw
A trunk/svn_check.dsp
A trunk/COMMITTERS
@@ -49,12 +49,15 @@
Checked out revision 2499.
@end example
+Subversion commands usually have short forms. In this case, @samp{svn
+checkout} can be shortened to @samp{svn co}.
+
Although the above example checks out the trunk directory, you can just
as easily checkout any deep subdirectory of a repository by specifying
the subdirectory in the checkout URL:
@example
-$ svn co http://svn.collab.net/repos/svn/trunk/doc/handbook
+$ svn checkout http://svn.collab.net/repos/svn/trunk/doc/handbook
A handbook/svn-handbook.texi
A handbook/getting_started.texi
A handbook/outline.txt
@@ -84,7 +87,7 @@
copy into a new directory that you name. For example:
@example
-$ svn co http://svn.collab.net/repos/svn/trunk subv
+$ svn checkout http://svn.collab.net/repos/svn/trunk subv
A subv/subversion.dsw
A subv/svn_check.dsp
A subv/COMMITTERS
@@ -119,7 +122,7 @@
@end itemize
@c ---------------
-@subsection Update your working copy (@samp{svn up})
+@subsection Update your working copy (@samp{svn update})
When working on a project with a team, you'll want to @dfn{update}
your working copy: that is, receive any changes from other developers
@@ -166,22 +169,22 @@
-@subsection Make changes (@samp{svn add}, @samp{svn rm}, @samp{svn
cp}, @samp{svn mv})
+@subsection Make changes (@samp{svn add}, @samp{svn delete},
@samp{svn copy}, @samp{svn move})
Now you can to get to work and make changes in your working copy. It's
-usually most convenient to create a ``task'' for yourself, such as
+usually most convenient to create a task for yourself, such as
writing a new feature, fixing a bug, etc.
What kinds of changes can you make to your working copy tree?
@table @b
@item File changes
-This is the simplest sort of change. Unlike other revision control
+This is the simplest sort of change. Unlike some other revision
control
systems, you don't need to tell Subversion that you intend to change a
file; just do it. Later on, Subversion will be able to automatically
detect which files have been changed.
@item Tree changes
-You can ask Subversion to ``mark'' files and directories for scheduled
+You can ask Subversion to mark files and directories for scheduled
removal or addition. Of course, no additions or removals will happen
in the repository until you decide to commit.
@end table
@@ -201,20 +204,20 @@
directory. Note that if @file{foo} is a directory, only the directory
itself will be scheduled for addition. If you want to add its
contents as well, pass the @option{--recursive} switch.
-@item @samp{svn rm @file{foo}}
+@item @samp{svn delete @file{foo}}
Schedule @file{foo} to be removed from the repository. If @file{foo}
is a file, it immediately vanishes from the working copy -- but it can
be recovered with @samp{svn revert} (see below). If @file{foo} is
a directory, it is merely scheduled for deletion. After you commit,
@file{foo} will no longer exist in the working copy or repository.
-@item @samp{svn cp @file{foo} @file{bar}}
+@item @samp{svn copy @file{foo} @file{bar}}
Create new item @file{bar} as a duplicate of @file{foo}. @file{bar}
is automatically scheduled for addition. When @file{bar} is added to
the repository on the next commit, it's copy-history is recorded (as
having originally come from @file{foo}.)
-@item @samp{svn mv @file{foo} @file{bar}}
-This command is exactly the same as running @samp{svn cp foo bar;
-svn rm foo}. That is, @file{bar} is scheduled for addition as a copy
+@item @samp{svn move @file{foo} @file{bar}}
+This command is exactly the same as running @samp{svn copy foo bar;
+svn delete foo}. That is, @file{bar} is scheduled for addition as a
copy
of @file{foo}, and @file{foo} is scheduled for removal.
@end table
@@ -222,9 +225,13 @@
that immediately commit tree changes to the repository. This usually
happens when a subcommand is operating directly on a URL, rather than
on a working-copy path. (In particular, specific uses of @samp{svn
-mkdir}, @samp{svn cp}, @samp{svn mv}, and @samp{svn rm} can work with
+mkdir}, @samp{svn copy}, @samp{svn move}, and @samp{svn delete} can
work with
URLs. See @samp{svn help} on these commands for more details.)
+## The above para does very little to help me understand when this
+happens, or whether I should worry about it now or pretend it's not an
+issue until I encounter it... Can we clarify? -wsv
+
@subsection Examine your changes (@samp{svn status}, @samp{svn diff},
@samp{svn revert})
So now you've finished your changes@dots{} or so you think. But what
@@ -232,7 +239,7 @@
Subversion has been optimized to help you with this task, and is able
to do many things without talking to the repository or network at all.
-In particular, your working copy contains a secret cached ``pristine''
+In particular, your working copy contains a secret cached pristine
copy of each file within the @file{.svn} area. Because of this, it
can quickly show you how your working files have changed, or even
allow you to undo your changes.
@@ -306,10 +313,10 @@
columns. The first @samp{_} is just printed to make it clear to the
eye
that the properties are modified and not the contents.
-The third column will only show whitespace or a @samp{L} which means
-that @command{svn} has locked item locked in the @file{.svn} working
+The third column will only show whitespace or an @samp{L} which means
+that @command{svn} has locked the item in the @file{.svn} working
area. You will see @samp{L} if you run @samp{svn status} in a
directory
-you are currently running @samp{svn commit} when you are editing the
log
+where you are currently running @samp{svn commit} and are editing the
log
message. If there are no running @command{svn}'s, then presumably
@command{svn} was forcibly quit or died and the lock needs to be
cleaned
up by running @samp{svn cleanup}. Locks typically appear if a
@@ -318,7 +325,7 @@
The forth column will only show whitespace or a @samp{+} which means
that the file or directory is scheduled to be added or modified with
additional attached history. This typically happens when you @samp{svn
-mv} or @samp{svn cp} a file or directory. If you see @samp{A @ @ +},
+move} or @samp{svn copy} a file or directory. If you see @samp{A @ @
+},
this means the item is scheduled for addition-with-history. It could
be
a file, or the root of a copied directory. @samp{_ @ @ +} means the
item is part of a subtree scheduled for addition-with-history, i.e.
some
@@ -337,7 +344,8 @@
irrespective of @samp{svn status} and @samp{svn:ignore}'s regular
expressions, then use the @option{--no-ignore} command line option.
-If a single path is passed to the command, it will tell you about it:
+If a single path is passed to the command, it will tell you about that
+item only:
@example
$ svn status stuff/fish.c
@@ -431,7 +439,7 @@
@end example
The @samp{svn diff} command produces this output by comparing your
-working files against the cached ``pristine'' copies within the
+working files against the cached pristine copies within the
@file{.svn} area. Files scheduled for addition are displayed as all
added-text, and files scheduled for deletion are displayed as all
deleted text.
@@ -449,7 +457,7 @@
@end example
The file is reverted to its pre-modified state by overwriting it with
-the cached ``pristine'' copy. But also note that @samp{svn revert}
+the cached pristine copy. But also note that @samp{svn revert}
can undo any scheduled operations -- in case you decide that you don't
want to add a new file after all, or that you don't want to remove
something.
@@ -487,7 +495,7 @@
@itemize @bullet
@item
a @samp{C} is printed during the update, and Subversion remembers that
the
-file is ``conflicted''.
+file is conflicted.
@item
three fulltext files starting with @file{tmp} are created; these files
are the original three files that could not be merged together.
@@ -531,9 +539,9 @@
Another way to specify a log message is to place it in a file, and
pass the filename with the @option{-F} switch. If you fail to
-specify either the @option{-m} or @option{-F} switch, then Subversion
will
-automatically launch your favorite @samp{$EDITOR} for composing a log
-message.
+specify either the @option{-m} or @option{-F} switch, then Subversion
+will automatically launch your favorite editor (specified in the
+environment variable @samp{$EDITOR}) for composing a log message.
The repository doesn't know or care if your changes make any sense as
a whole; it only checks to make sure that nobody else has changed any
@@ -615,7 +623,7 @@
And while we're on the subject, @samp{svn log} also takes a
@option{--verbose} (@option{-v}) option too; it includes a list of
-changed-paths in each revision:
+changed paths in each revision:
@example
$ svn log -r 8 -v
@@ -642,7 +650,7 @@
@subsubsection Examining local changes
Invoking @samp{svn diff} with no switches will compare your working
-files to the cached ``pristine'' copies in the @file{.svn} area:
+files to the cached pristine copies in the @file{.svn} area:
@example
$ svn diff foo
@@ -713,18 +721,18 @@
@dfn{revisions}, @xref{Transactions and Revision Numbers}, or
@xref{Revision numbers are different now}.)
-As you may have suspected, the filesystem doesn't grow 652 new inodes
+As you may have suspected, the filesystem doesn't grow 652 new nodes
each time a new revision is created. Instead, each new tree is
@emph{mostly} made of pointers to already-existing nodes; new nodes
are created only for changed items, and all the rest of the revision
-tree is ``shared storage'' with other revision trees. This technique
-demonstrates how the filesystem is able to make ``cheap copies'' of
-things. These cheap copies are nothing more than directory entries
-that point to existing nodes. And this is the basis of tags and
-branches.
+tree is shared storage with other revision trees. This technique
+demonstrates how the filesystem is able to make cheap copies of
+items. These cheap copies are nothing more than directory entries
+that point to existing nodes. And this mechanism is also the basis
+of tags and branches.
-@subsection Branching with @samp{svn cp}
+@subsection Branching with @samp{svn copy}
Suppose we have a repository whose head tree is revision 82. In this
repository is a subdirectory @file{mooIRC} that contains a software
@@ -735,13 +743,13 @@
revision 82. Of course, you can name the new directory entry whatever
you want -- probably a tag-name like @file{mooIRC-beta}.
-The easiest way to make this copy is with @samp{svn cp}, which,
+The easiest way to make this copy is with @samp{svn copy}, which,
incidentally, can operate entirely on URLs, so that the copy happens
only on the server-side:
@example
-$ svn cp http://foo.com/repos/mooIRC \
- http://foo.com/repos/mooIRC-beta
+$ svn copy http://foo.com/repos/mooIRC \
+ http://foo.com/repos/mooIRC-beta
Committed revision 83.
@end example
@@ -759,7 +767,7 @@
@dfn{branches} of the project.
It's very important to note that the Subversion filesystem is
-@emph{not} aware of ``tags'' or ``branches.'' It's only aware of
+@emph{not} aware of tags or branches. It's only aware of
directories, and all directories are equal. The tag and branch
concepts are purely @emph{human} meanings attached to particular
directories.
@@ -808,11 +816,11 @@
@subsection Switching to a branch with @samp{svn switch}
-The @samp{svn switch} command allows you to ``move'' some or all of
+The @samp{svn switch} command allows you to move some or all of
your working copy to a branch or tag. For example, suppose I have a
working copy of @file{mooIRC}, and I'd like to work on some subsystem
as it appears in a subdirectory of @file{mooIRC-beta}. At the same
-time, I want the rest my working copy to remain on the original
+time, I want the rest of my working copy to remain on the original
@file{mooIRC} branch. To do this, I switch the appropriate subdir to
the new branch location:
@@ -937,7 +945,7 @@
Sometimes you want to manage modified third-party source code inside
your
Subversion repository, while still tracking upstream releases. In CVS
this would have been called a ``vendor branch''. Subversion doesn't
have
-a formal ``vendor branch'', but it is sufficiently flexible that you
can
+a formal vendor branch feature, but it is sufficiently flexible that
you can
still do much the same thing.
The general procedure goes like this. You create a top level
@@ -980,13 +988,13 @@
additions or removals manually, and then commit.
@example
-$ svn co http://svnhost/repos/vendor/foobar/current ~/current
+$ svn checkout http://svnhost/repos/vendor/foobar/current ~/current
$ cd ~/foobar-1.1
$ tar -cf - . | (cd ~/current ; tar -xf -)
$ cd ~/current
$ mv foobar.c main.c
-$ svn mv main.c foobar.c
-$ svn rm dead.c
+$ svn move main.c foobar.c
+$ svn delete dead.c
$ svn add doc
$ svn add doc/*
$ svn commit -m `importing foobar 1.1 on vendor branch'
@@ -998,7 +1006,7 @@
was renamed to @file{foobar.c} in 1.1. So your working-copy had the
old
@file{main.c} which @command{svn} knew about, and the new
@file{foobar.c} which @command{svn} did not know about. You rename
-@file{foobar.c} to @file{main.c} and @samp{svn mv} it back to the new
+@file{foobar.c} to @file{main.c} and @samp{svn move} it back to the new
name. This way, @command{svn} will know that @file{foobar.c} is a
descendant of @file{main.c}. @file{dead.c} has vanished in 1.1, and
they have finally written some documentation, so you add that.
@@ -1018,7 +1026,7 @@
That looks like this.
@example
-$ svn co http://svnhost/repos/trunk/foobar ~/foobar
+$ svn checkout http://svnhost/repos/trunk/foobar ~/foobar
$ cd ~/foobar
$ svn merge http://svnhost/repos/vendor/foobar/foobar-1.0 \
http://svnhost/repos/vendor/foobar/foobar-1.1
@@ -1171,14 +1179,14 @@
files, hence the @samp{svn:mime-type} setting of
@samp{application/msword}.
-@subsection Removing a branch or tag with @samp{svn rm}
+@subsection Removing a branch or tag with @samp{svn delete}
-The @samp{svn rm} command can operate on URLs. A file or directory
-can be ``remotely'' deleted from the repository, with no working copy
+The @samp{svn delete} command can operate on URLs. A file or directory
+can be remotely deleted from the repository, with no working copy
present:
@example
-$ svn rm http://foo.com/repos/tags/mooIRC-bad-tag -m "deleting bad tag"
+$ svn delete http://foo.com/repos/tags/mooIRC-bad-tag -m "deleting bad
tag"
Committed revision 1023.
@end example
@@ -1245,7 +1253,7 @@
text file. This is exceptionally convenient for properties that are a
newline-separated array of values. (See below.)
-Property changes are still considered ``local modifications'', and
+Property changes are still considered local modifications, and
aren't permanent until you commit. Like textual changes, property
changes can be seen by @samp{svn diff}, @samp{svn status}, and
reverted altogether with @samp{svn revert}:
@@ -1264,7 +1272,7 @@
Notice that a 2nd column has appeared in the status output; the
leading underscore indicates that you've not made any textual changes,
but the @samp{M} means you've modified the properties. @samp{svn
-status} tries to hide the 2nd ``property'' column when an item has no
+status} tries to hide the 2nd property column when an item has no
properties at all; this was a design choice, to ease new users into
the concept. When properties are created, edited, or updated on an
item, that 2nd column appears forever after.
@@ -1424,7 +1432,7 @@
``native''. This makes the file always appear with the ``native''
line endings of each developer's operating system. Note, however,
that the file will always contain LF endings in the repository. This
-prevents the line-ending ``churn'' from revision to revision.
+prevents the line-ending churn from revision to revision.
Alternately, you can force files to always retain a fixed, specific
line ending: set a file's @samp{svn:eol-style} property to one of
@@ -1452,7 +1460,7 @@
exactly how you want the final working copy to be?
This is known as a @dfn{module}. You can define a module by attaching
-another special ``magic'' @samp{svn:} property to a directory: the
+another special magic @samp{svn:} property to a directory: the
@samp{svn:externals} property.
The value of this property is a list of subdirectories and
@@ -1510,7 +1518,7 @@
@item HEAD
The latest revision in the repository.
@item BASE
-The ``pristine'' revision of an item in a working copy.
+The pristine revision of an item in a working copy.
@item COMMITTED
The last revision in which an item changed.
@item PREV
@@ -1518,6 +1526,8 @@
changed. (Technically, COMMITTED - 1).
@end table
+## Clarify: How is this COMMITTED different from HEAD? When do you
care?
+
Here are some examples of revision keywords in action:
@example
@@ -1566,7 +1576,7 @@
And this is exactly what @samp{svn cleanup} does: it searches your
working copy and re-runs any leftover logs, removing locks in the
process. Use this command if Subversion ever tells you that some part
-of your working copy is ``locked''. Also, @samp{svn status} will
+of your working copy is locked. Also, @samp{svn status} will
display an @samp{L} next to locked items:
@example
@@ -1677,7 +1687,8 @@
@subheading @samp{svn ls}
-The ls command lets you find what files are in a repository directory.
+The ls command lets you find out information about files in a
repository
+directory.
@example
$ svn ls http://svn.collab.net/repos/svn
@@ -1751,14 +1762,14 @@
Soon -- very soon -- a @file{config} file will exist in this area for
defining general user preferences. For example, the preferred
-@samp{$EDITOR} to use, options to pass through to @samp{svn diff},
+editor to use, options to pass through to @samp{svn diff},
preferences for date/time formats, and so on. See issue #668 for
details
(@uref{http://subversion.tigris.org/issues/show_bug.cgi?id=668}).
@subsection Multiple config areas
-On Unix, an administrator can create``global'' Subversion preferences
+On Unix, an administrator can create global Subversion preferences
by creating and populating an @file{/etc/subversion/} area. The
per-user @file{~/.subversion/} configuration will still override these
defaults, however.
Index: ./doc/handbook/repos_admin.texi
===================================================================
--- ./doc/handbook/repos_admin.texi
+++ ./doc/handbook/.svn/tmp/repos_admin.texi.62480.00001.tmp Thu Aug
15 09:51:02 2002
@@ -224,12 +224,12 @@
@subsection the shell
-The @command{svnadmin} tool has a toy ``shell'' mode as well. It
doesn't
+The @command{svnadmin} tool has a ``shell'' mode as well. It doesn't
do much, but it allows you to poke around the repository as if it were
an imaginary mounted filesystem. The basic commands @samp{cd},
@samp{ls}, @samp{exit}, and @samp{help} are available, as well
-as the very special command @samp{cr} -- ``change revision.'' The last
-command allows you to move @emph{between} revision trees.
+as the very special command @samp{cr} (change revision), that allows
+you to switch to a different revision tree.
@example
$ svnadmin shell repos
@@ -328,7 +328,7 @@
@file{tools/hook-scripts/commit-access-control.pl} script that can be
called from @file{pre-commit} to implement fine-grained access control.
-@item post-commit
+@item @file{post-commit}
This is run after the transaction is committed, and we have a new
revision. Most people use this hook to send out descriptive
commit-emails or to make a hot-backup of the repository. The
repository
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 15 16:08:27 2002