bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Patch: documentation cleanup


From: Jim.Hyslop
Subject: Patch: documentation cleanup
Date: Mon, 17 May 2004 11:11:22 -0400

Changelog:
* Cleaned up the documentation with respect to renaming and moving
directories.

Index: cvs.texinfo
===================================================================
RCS file: /cvs/ccvs/doc/cvs.texinfo,v
retrieving revision 1.607
diff -u -p -r1.607 cvs.texinfo
--- cvs.texinfo 14 May 2004 16:09:34 -0000      1.607
+++ cvs.texinfo 17 May 2004 15:04:33 -0000
@@ -5240,7 +5240,7 @@ commands while you move it.
 @subsection Copying the history file
 
 This way also involves direct modifications to the
-repository.  It is safe, but not without drawbacks.
+repository.  It is safer, but not without drawbacks.
 
 @example
 # @r{Copy the @sc{rcs} file inside the repository}
@@ -5251,16 +5251,28 @@ $ cd ~/@var{dir}
 $ rm @var{old}
 $ cvs remove @var{old}
 $ cvs commit @var{old}
-# @r{Remove all tags from @var{new}}
+# @r{Remove all non-branch tags from @var{new}}
 $ cvs update @var{new}
-$ cvs log @var{new}             # @r{Remember the non-branch tag names}
+$ cvs log @var{new}
 $ cvs tag -d @var{tag1} @var{new}
 $ cvs tag -d @var{tag2} @var{new}
 @dots{}
+# @r{Remove all branch tags from @var{old}}
+$ cvs tag -dB @var{branch-tag1} @var{old}
+$ cvs tag -dB @var{branch-tag2} @var{old}
+@dots{}
 @end example
 
-By removing the tags you will be able to check out old
-revisions.
+Note: a branch tag is indicated by a @samp{0}
+as the revision number, in the second-to-last field. For example,
+@samp{tag1: 1.2.0.2} indicates that tag @code{tag1} is a branch
+tag, and @samp{tag2: 1.2.2.10} indicates that tag @code{tag2}
+is a non-branch tag.
+
+If you do not remove the tags, then you will get two copies
+of the file when you check out based on a tag: one in the old
+directory, one in the new directory.
+
 
 @noindent
 Advantages:
@@ -5287,18 +5299,6 @@ Disadvantages:
 @item
 You cannot easily see the history of the file across the rename.
 
-@ignore
-@c Is this true?  I don't see how the revision numbers
-@c _could_ start over, when new,v is just old,v with
-@c the tags deleted.
-@c If there is some need to reinstate this text,
-@c it is "usually 1.1", not "1.0" and it needs an
-@c xref to Assigning revisions
-@item
-Unless you use the @samp{-r rev} (@pxref{commit
-options}) flag when @var{new} is committed its revision
-numbers will start at 1.0 again.
-@end ignore
 @end itemize
 
 @c ---------------------------------------------------------------------
@@ -5346,9 +5346,9 @@ If someone had a working copy the @sc{cv
 cease to work for him, until he removes the directory
 that disappeared inside the repository.
 
-It is almost always better to move the files in the
-directory instead of moving the directory.  If you move the
-directory you are unlikely to be able to retrieve old
+It is almost always better to move the files in your working
+copy instead of moving the directory in the repository.  If you move the
+directory in the repository, you are unlikely to be able to retrieve old
 releases correctly, since they probably depend on the
 name of the directories.
 


-- 
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. (http://www.leitch.com)
Columnist, C/C++ Users Journal (http://www.cuj.com/experts)







reply via email to

[Prev in Thread] Current Thread [Next in Thread]