Hi,
I noticed a few typos in the "Subversion for CVS Users" document. I think
the appended patch is self-explanatory except for this section, which I've
prefaced with extra leading context for clarity:
@@ -156,15 +156,15 @@
If you specify either the -u or -v switch, a "long" format is used:
@example
% svn status
M 1047 ./foo.c
_ * 1045 ./faces.html
_ * - ./bloo.png
M 1050 ./bar/baz.c
Head revision: 1066
@end example
-In this case, two new columns appear. The first column potentially
-contains an asterisk, which means that the file or directory is
-out-of-date. The second column shows the working-copy's revision
+In this case, two new columns appear. The second column
+contains an asterisk if the file or directory is
+out-of-date. The third column shows the working-copy's revision
number of the item. In the example above, the asterisk indicates that
When first reading the above, I had to reparse a couple of times to
realize that "first column" referred not to the first column in the table
but to the first of the two added columns, i.e. the second column in the
table.
Nick Duffek
nick@duffek.com
[patch follows]
Index: doc/user/svn_for_cvs_users/svn_for_cvs_users.texi
===================================================================
--- doc/user/svn_for_cvs_users/svn_for_cvs_users.texi
+++ doc/user/svn_for_cvs_users/svn_for_cvs_users.texi Thu Jun 27 13:01:24 2002
@@ -69,7 +69,7 @@
repository is an array of trees. Each of these trees is labeled with
a single revision number. When someone talks about "revision 54",
they're talking about a particular tree (and indirectly, the way the
-filesystem looked after the 54th commit.)
+filesystem looked after the 54th commit).
Technically, it's not valid to talk about "revision 5 of foo.c".
Instead, one would say "foo.c as it appears in revision 5". Also, be
@@ -164,9 +164,9 @@
Head revision: 1066
@end example
-In this case, two new columns appear. The first column potentially
-contains an asterisk, which means that the file or directory is
-out-of-date. The second column shows the working-copy's revision
+In this case, two new columns appear. The second column
+contains an asterisk if the file or directory is
+out-of-date. The third column shows the working-copy's revision
number of the item. In the example above, the asterisk indicates that
`faces.html' would be patched if we updated, and that `bloo.png' is a
newly added file in the repository. (The '-' next to bloo.png means
@@ -227,7 +227,7 @@
file has properties as well as text -- but that there's nothing
special about either portion. The second example is status's way of
reminding you that you have some locally modified properties on a file
-(but the text is unchanged.) The third example is update's way of
+(but the text is unchanged). The third example is update's way of
telling you that a file's properties were patched (but not its text).
The fourth example means that both components were patched.
@@ -290,7 +290,7 @@
CVS marks conflicts with in-line "conflict markers", and prints a 'C'
during an update. Historically, this has caused problems. Many users
-forget about (or don't see) the 'C' after it whizzes by their
+forget about (or don't see) the 'C' after it whizzes by on their
terminal. They often forget that the conflict-markers are even
present, and then accidentally commit garbaged files.
@@ -317,7 +317,7 @@
Finally, it's worth mentioning that properties can come into
conflict. If this happens, a description of the conflict will be
-dumped into '.prej' file instead.
+dumped into a '.prej' file instead.
@node Binary files
@@ -325,7 +325,7 @@
CVS users have to mark binary files with '-kb' flags, to prevent data
from being munged (due to keyword expansion and line-ending
-translations.) They sometimes forget to do this.
+translations). They sometimes forget to do this.
Subversion examines the "svn:mime-type" property to decide if a file
is text or binary. If the file has no "svn:mime-type" property,
@@ -380,11 +380,11 @@
This technique demonstrates how the filesystem is able to make
"cheap copies" of things. Remember that nodes are never, ever deleted
in the filesystem; at most, they're simply unlinked from the head tree
-(and they continue to stay linked to older trees.) These cheap copies
+(and they continue to stay linked to older trees). These cheap copies
are nothing more than directory entries that point to existing nodes.
And this is the basis of tags and branches.
-Suppose we have a have a repository whose head tree is revision 82. In
+Suppose we have a repository whose head tree is revision 82. In
this repository is a subdirectory 'mooIRC' that contains a software
project that is ready to be tagged. How do we tag it? Very simple:
make a cheap copy of this directory. In other words, create a new
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 27 19:30:09 2002