Mercurial > emacs

changeset 36385:d7ca85bd6906

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Clean up recent VC updates.
author Richard M. Stallman <rms@gnu.org>
date Sun, 25 Feb 2001 17:24:19 +0000
parents f9e19fa8951a
children cbfd0f2559ad
files man/files.texi
diffstat 1 files changed, 191 insertions(+), 184 deletions(-) [+]
line wrap: on
line diff
--- a/man/files.texi	Sun Feb 25 13:56:34 2001 +0000
+++ b/man/files.texi	Sun Feb 25 17:24:19 2001 +0000
@@ -1061,9 +1061,8 @@
 such as the creation time of each version, who created it, and a 
 description of what was changed in that version.
 
-  The Emacs version control interface is called VC.  It allows you to
-use various version control systems from within
-Emacs---currently, it supports RCS, CVS, and SCCS.  The GNU
+  The Emacs version control interface is called VC.  Its commands work
+with three version control systems---RCS, CVS, and SCCS.  The GNU
 project recommends RCS and CVS, which are free software and available
 from the Free Software Foundation.  We also have free software to
 replace SCCS, known as CSSC; if you are using SCCS and don't want to
@@ -1226,7 +1225,7 @@
 @menu
 * VC with Locking::     RCS in its default mode, SCCS, and optionally CVS.
 * Without Locking::     Without locking: default mode for CVS.
-* Extended Actions::    Avanced features available with a prefix argument.
+* Extended C-x C-q::    Advanced features available with a prefix argument.
 * Log Buffer::          Features available in log entry buffers.
 @end menu
                
@@ -1274,11 +1273,11 @@
 
 @itemize @bullet
 @item
-If some other user has checked in changes into the master file,
-Emacs asks you whether you want to merge those changes into your own
-work file.  You must do this before you can check in
-your own changes.  (To pick up any recent changes from the master file
-@emph{without} trying to commit your own changes, type @kbd{C-x v m RET}.)
+If some other user has checked in changes into the master file, Emacs
+asks you whether you want to merge those changes into your own work
+file.  You must do this before you can check in your own changes.  (To
+pick up any recent changes from the master file @emph{without} trying
+to commit your own changes, type @kbd{C-x v m @key{RET}}.)
 @xref{Merging}.
 
 @item
@@ -1306,29 +1305,33 @@
 it is not required; @kbd{C-x C-q} with an unmodified file locks the
 file, just as it does with RCS in its normal (locking) mode.
 
-@node Extended Actions
-@subsubsection Calling @code{vc-next-action} with a Prefix Argument
-
-When you give a prefix argument to @code{vc-next-action} (@kbd{C-u C-x
-C-q}), it still performs the next logical version control operation, but
-in an extended sense.
+@node Advanced C-x C-q
+@subsubsection Advanced Control in @kbd{C-x C-q}
+
+  When you give a prefix argument to @code{vc-next-action} (@kbd{C-u
+C-x C-q}), it still performs the next logical version control
+operation, but accepts additional arguments to specify precisely how
+to do the operation.
 
 @itemize @bullet
-@item If the file is modified (or locked), you can specify the version
-number that should be used for check-in.  This is also one way to create
-a new branch (@pxref{Branches}).
-
-@item If the file is not modified (and unlocked), you can specify a new
-version to go to; this lets you start working from an older version, or
-on another branch.  If you do not enter any version, that takes you to
-the highest version on the current branch; therefore @kbd{C-u C-x C-q
-RET} is a convenient way to get the latest version of a file from the
-repository.
-
-@item Regardless of the state of the file, you can also enter the name
-of another version control system instead of a version number.  This
-lets you use more than one version control system for a file
-(@pxref{Local Version Control}).
+@item
+If the file is modified (or locked), you can specify the version
+number to use for the new verion that you check-in.  This is one way
+to create a new branch (@pxref{Branches}).
+
+@item
+If the file is not modified (and unlocked), you can specify the
+version to select; this lets you start working from an older version,
+or on another branch.  If you do not enter any version, that takes you
+to the highest version on the current branch; therefore @kbd{C-u C-x
+C-q @key{RET}} is a convenient way to get the latest version of a file from
+the repository.
+
+@item
+Instead of the version number, you can also specify the name of a
+version control system.  This is useful when one file is being managed
+with two version control systems at the same time file (@pxref{Local
+Version Control}).
 @end itemize
 
 @node Log Buffer
@@ -1393,33 +1396,33 @@
   It is usually more convenient to compare two versions of the file,
 with the command @kbd{C-x v =} (@code{vc-diff}).  Plain @kbd{C-x v =}
 compares the current buffer contents (saving them in the file if
-necessary) with the last checked-in version of the file.  @kbd{C-u C-x v
-=}, with a numeric argument, reads a file name and two version numbers,
-then compares those versions of the specified file.
-
-  If you supply a directory name instead of the name of a registered
-file, this command compares the two specified versions of all registered
-files in that directory and its subdirectories.
+necessary) with the last checked-in version of the file.  @kbd{C-u C-x
+v =}, with a numeric argument, reads a file name and two version
+numbers, then compares those versions of the specified file.  Both
+forms display the output in a special buffer in another window.
 
   You can specify a checked-in version by its number; an empty input
 specifies the current contents of the work file (which may be different
 from all the checked-in versions).  You can also specify a snapshot name
 (@pxref{Snapshots}) instead of one or both version numbers.
 
+  If you supply a directory name instead of the name of a registered
+file, this command compares the two specified versions of all registered
+files in that directory and its subdirectories.
+
 @vindex diff-switches
 @vindex vc-diff-switches
-  This command works by running a variant of the @code{diff} utility
-that is specific to the version control system in use.  Emacs passes the
-contents of the variable @code{diff-switches} to that utility; you can
-define specific options for version control in @code{vc-diff-switches},
-and there are similar variables for each specific system,
-e.g. @code{vc-rcs-diff-switches}, and the like.
-
-  The output of the @code{diff} command is displayed in a special buffer
-in another window.  Unlike the @kbd{M-x diff} command, @kbd{C-x v =}
-does not try to locate the changes in the old and new versions.  This is
-because normally one or both versions do not exist as files when you
-compare them; they exist only in the records of the master file.
+  @kbd{C-x v =} works by running a variant of the @code{diff} utility
+designed to work with the version control system in use.  Emacs passes
+the contents of the variable @code{diff-switches} to it; you can
+specify comparison options for version control in
+@code{vc-diff-switches}, and there are similar variables for each
+specific system---@code{vc-rcs-diff-switches}, and so on.
+
+  Unlike the @kbd{M-x diff} command, @kbd{C-x v =} does not try to
+locate the changes in the old and new versions.  This is because
+normally one or both versions do not exist as files when you compare
+them; they exist only in the records of the master file.
 @xref{Comparing Files}, for more information about @kbd{M-x diff}.
 
 @findex vc-annotate
@@ -1469,9 +1472,8 @@
 its directory is not already part of a CVS tree.
 
   With the default value of @var{vc-handled-backends}, this means that
-Emacs uses RCS if there are any files under RCS control, and CVS if
-there are any files under CVS.  If there are no files under version
-control, RCS is used.
+Emacs uses RCS if there are any files under RCS control, or CVS if
+there are any files under CVS, or RCS as the ultimate default.
 
   If locking is in use, @kbd{C-x v i} leaves the file unlocked and
 read-only.  Type @kbd{C-x C-q} if you wish to start editing it.  After
@@ -1722,7 +1724,7 @@
 
   You can omit the minor version number, thus giving only the branch
 number; this takes you to the head version on the chosen branch.  If you
-only type @kbd{RET}, Emacs goes to the highest version on the trunk.
+only type @key{RET}, Emacs goes to the highest version on the trunk.
 
   After you have switched to any branch (including the main branch), you
 stay on it for subsequent VC commands, until you explicitly select some
@@ -1781,7 +1783,7 @@
   @kbd{C-x v m} (@code{vc-merge}) takes a set of changes and merges it
 into the current version of the work file.  It firsts asks you in the
 minibuffer where the changes should come from.  If you just type
-@kbd{RET}, Emacs merges any changes that were made on the same branch
+@key{RET}, Emacs merges any changes that were made on the same branch
 since you checked the file out (we call this @dfn{merging the news}).
 This is the common way to pick up recent changes from the repository,
 regardless of whether you have already changed the file yourself.
@@ -1795,9 +1797,9 @@
 branch 1.3.1.  In the meantime, development on the trunk has proceeded
 to version 1.5.  To merge the changes from the branch to the trunk,
 first go to the head version of the trunk, by typing @kbd{C-u C-x C-q
-RET}.  Version 1.5 is now current.  If locking is used for the file,
+@key{RET}}.  Version 1.5 is now current.  If locking is used for the file,
 type @kbd{C-x C-q} to lock version 1.5 so that you can change it.  Next,
-type @kbd{C-x v m 1.3.1 RET}.  This takes the entire set of changes on
+type @kbd{C-x v m 1.3.1 @key{RET}}.  This takes the entire set of changes on
 branch 1.3.1 (relative to version 1.3, where the branch started, up to
 the last version on the branch) and merges it into the current version
 of the work file.  You can now check in the changed file, thus creating
@@ -1867,16 +1869,15 @@
 @subsection Remote Repositories
 @cindex remote repositories (CVS)
 
-Many projects set up a central CVS repository somewhere in the Internet,
-and let each user check out a personal working copy of the files to
-his local machine.  Committing changes to the repository, and picking
-up changes from other users into one's own working area, then works by
-direct interactions with the CVS server.  
-
-The problem is that access to the CVS server is often slow, and that
-developers might need to work offline as well.  VC therefore offers
-some features that allow you to keep network interactions to a
-minimum.
+  A common way of using CVS is to set up a central CVS repository on
+some Internet host, then have each developer check out a personal
+working copy of the files on his local machine.  Committing changes to
+the repository, and picking up changes from other users into one's own
+working area, then works by direct interactions with the CVS server.
+
+  One difficulty is that access to the CVS server is often slow, and
+that developers might need to work offline as well.  VC is designed
+to reduce the amount of network interaction necessary.
 
 @menu
 * Version Backups::        Keeping local copies of repository versions.
@@ -1887,45 +1888,50 @@
 @subsubsection Version Backups
 @cindex version backups
 
-When VC sees that the CVS repository for a file is on a remote machine,
-it automatically makes local backups of unmodified versions of the file.
-This means that you can compare the file to the repository version
-(@kbd{C-x v =}), or revert to that version (@kbd{C-x v u}), without any
-network interactions.
-
-The local copy of the unmodified file is called a @dfn{version backup}.
-This is to indicate that it corresponds exactly to a version that is
-stored in the repository.  Note that version backups are related to,
-but distinct from the other kinds of backups that Emacs can make:
-single backups and numbered backups (@pxref{Backup}).
-
-@vindex vc-cvs-stay-local
-For a file that comes from a remote CVS repository, VC makes a version
-backup whenever you save the first changes to the file, and removes it
-after you have committed your modified version to the repository.  (You
-can switch this off by setting the variable @code{vc-cvs-stay-local} to
-@code{nil}.)
-
 @cindex automatic version backups
+  When VC sees that the CVS repository for a file is on a remote
+machine, it automatically makes local backups of unmodified versions
+of the file---@dfn{automatic version backups}.  This means that you
+can compare the file to the repository version (@kbd{C-x v =}), or
+revert to that version (@kbd{C-x v u}), without any network
+interactions.
+
+  The local copy of the unmodified file is called a @dfn{version
+backup} to indicate that it corresponds exactly to a version that is
+stored in the repository.  Note that version backups are not the same
+as ordinary Emacs backup files (@pxref{Backup}).  But they follow a
+similar naming convention.
+
+  For a file that comes from a remote CVS repository, VC makes a
+version backup whenever you save the first changes to the file, and
+removes it after you have committed your modified version to the
+repository. You can disable the making of automatic version backups by
+setting @code{vc-cvs-stay-local} to @code{nil} (@pxref{CVS Options}).
+
 @cindex manual version backups
-The name of a version backup for a file named @var{file}, with version
-@var{version}, is @code{@var{file}.~@var{version}.~}.  Note that this
-naming convention is almost the same as that used by @kbd{C-x v ~}
-(@pxref{Old Versions}), the only difference being the additional dot
-(@samp{.}) after the version number.  This similarity is intentional,
-because both kinds of files store the same kind of information.  To
-distinguish between them, we speak of @dfn{automatic version backups}
-(those created by the mechanism described here) and @dfn{manual version
-backups} (created by @kbd{C-x v ~}).  Their primary difference is that
-Emacs deletes automatic version backups when you commit to the
-repository (this is why the trailing dot is needed to identify them),
-while manual version backups are never deleted automatically.
-
-Each of the two mechanisms can use the files created by the other one.
-For example, if you changed a file outside of Emacs, so that no
-automatic version backup was created, you can create a manual backup of
-that version using @kbd{C-x v ~}.  Emacs will then use that file for
-local diff and revert operations.
+  The name of the automatic version backup for version @var{version}
+of file @var{file} is @code{@var{file}.~@var{version}.~}.  This is
+almost the same as the name used by @kbd{C-x v ~} (@pxref{Old
+Versions}), the only difference being the additional dot (@samp{.})
+after the version number.  This similarity is intentional, because
+both kinds of files store the same kind of information.  The file made
+by @kbd{C-x v ~} acts as a @dfn{manual version backup}.
+
+  All the VC commands that operate on old versions of a file can use
+both kinds of version backups.  For instance, @kbd{C-x v ~} uses
+either an automatic or a manual version backup, if possible, to get
+the contents of the version you request.  Likewise, @kbd{C-x v =} and
+@kbd{C-x v u} use either an automatic or a manual version backup, if
+one of them exists, to get the contents of a version to compare or
+revert to.  If you changed a file outside of Emacs, so that no
+automatic version backup was created for the previous text, you can
+create a manual backup of that version using @kbd{C-x v ~}, and thus
+obtain the benefit of the local copy for Emacs commands.
+
+  The only difference in Emacs's handling of manual and automatic
+version backups, once they exist, is that Emacs deletes automatic
+version backups when you commit to the repository.  By contrast,
+manual version backups remain until you delete them.
 
 @node Local Version Control
 @subsubsection Local Version Control
@@ -1945,27 +1951,26 @@
 mechanism works with any combination of version control systems
 (@dfn{back ends}).
 
-To make it work with other back ends, you must make sure that the "more
-local" back end comes before the "more remote" back end in the setting
-of @var{vc-handled-backends} (@pxref{Customizing VC}).  By default, this
-variable is set up correctly so that you can use RCS and CVS as
-described here.
-
-To start using local RCS for a file that comes from a remote CVS server,
-you must @dfn{commit the file to RCS}, by typing @kbd{C-u C-x v v rcs
-RET}.  (In other words, @code{vc-next-action}, when called with a prefix
-argument, accepts a back end name in place of the version to commit to.)
-VC then registers the file under RCS.
-
-You can commit to RCS at any time; it does not matter whether you have
+To make it work with other back ends, you must make sure that the
+``more local'' back end comes before the ``more remote'' back end in
+the setting of @var{vc-handled-backends} (@pxref{Customizing VC}).  By
+default, this variable is set up so that you can use remote CVS and
+local RCS as described here.
+
+To start using local RCS for a file that comes from a remote CVS
+server, you must @emph{register the file in RCS}, by typing @kbd{C-u
+C-x v v rcs @key{RET}}.  (In other words, use @code{vc-next-action} with a
+prefix argument, and specify RCS as the back end.)
+
+You can do this at any time; it does not matter whether you have
 already modified the file with respect to the version in the CVS
 repository.  If possible, VC tries to make the RCS master start with
 the unmodified repository version, then checking in any local changes
-as a new version.  This works if you have not made any changes yet,
-or if the unmodified repository version exists locally as a version
+as a new version.  This works if you have not made any changes yet, or
+if the unmodified repository version exists locally as a version
 backup (@pxref{Version Backups}).  If the unmodified version is not
 available locally, the RCS master starts with the modified version;
-the only problem with this is that you cannot compare your changes
+the only drawback of this is that you cannot compare your changes
 locally to what is stored in the repository.
 
 The version number of the RCS master is derived from the current CVS
@@ -1973,55 +1978,61 @@
 version is 1.23, the local RCS branch will be 1.23.1.  Version 1.23 in
 the RCS master will be identical to version 1.23 under CVS; your first
 changes are checked in as 1.23.1.1.  (If the unmodified file is not
-available locally, VC will check-in the modified file twice, both as
+available locally, VC will check in the modified file twice, both as
 1.23 and 1.23.1.1, to make the revision numbers consistent.)
 
 If you do not use locking under CVS (the default), locking is also
-switched off under RCS, so that editing under RCS works exactly as
-under CVS.  
-
-When you are done with your edits, you can commit the final version back
-to the CVS repository, typing @kbd{C-u C-x v v cvs RET}.  Emacs will
-initialize the log entry buffer (@pxref{Log Buffer}) to contain all the
-check-in comments you have made in the RCS master; you can make changes
-to these comments as needed and then commit to CVS by typing @kbd{C-c
-C-c}.  If the commit is successful, VC finally removes the RCS master,
-so that the file becomes once again registered under CVS only.  (The RCS
-master is not actually deleted, but renamed by adding a @samp{~} to its
-name, so that you can get back to it later if you want.)
-
-While you are working with a local RCS master, you might still want to
+disabled for RCS, so that editing under RCS works exactly as under
+CVS.
+
+When you are done with your edits, you can commit the final version
+back to the CVS repository, typing @kbd{C-u C-x v v cvs @key{RET}}.  Emacs
+will initialize the log entry buffer (@pxref{Log Buffer}) to contain
+all the log entries you have recorded in the RCS master; you can make
+changes to these comments as needed, and then commit in CVS by typing
+@kbd{C-c C-c}.  If the commit is successful, VC removes the RCS
+master, so that the file is once again registered under CVS only.
+(The RCS master is not actually deleted, just renamed by appending
+@samp{~} to the name, so that you can refer to it later if you wish.)
+
+While you are working with a local RCS master, you may still want to
 pick up recent changes from the CVS repository into your local file,
 or you might want to commit some of your changes back to CVS, without
-actually switching back to CVS completely.  VC lets you do this by
+actually switching back to CVS completely.  You can do this by
 switching to another backend temporarily.
 
 @table @kbd
 @item C-x v b
-Switch to any other back end that the current file is registered
+Switch to another back end that the current file is registered
 under (@code{vc-switch-backend}).
+
+@item C-u C-x v b @var{backend} @key{RET}
+Switch to @var{backend} for the current file.
 @end table
 
 @kindex C-x v b
 @findex vc-switch-backend
+@kbd{C-x v b} does not change the buffer contents, or any files; it
+only changes VC's perspective on how to handle the file.  Any
+subsequent VC commands for that file will operate on the back end that
+is currently selected.
+
 If the current file is registered in more than one back end, typing
-@kbd{C-x v b} lets you ``cycle'' through these back ends.  (With a prefix
-argument, it asks for the back end to use in the minibuffer.)  This
-command does not change any files, it only changes VC's perspective of
-the file.  Any other VC commands that you use on a file will operate on
-the back end that is currently selected.
+@kbd{C-x v b} ``cycles'' through all of these back ends.  With a
+prefix argument, it asks for the back end to use in the minibuffer.
 
 Thus, if you have a file under local RCS, and you want to pick up some
 recent changes from CVS, type @kbd{C-x v b} to switch to CVS, and then
-@kbd{C-x v m RET} to merge the news (@pxref{Merging}).  You can then switch
-back to RCS by typing @kbd{C-x v b} again, and continue to edit locally.
+@kbd{C-x v m @key{RET}} to merge the news (@pxref{Merging}).  You can
+then switch back to RCS by typing @kbd{C-x v b} again, and continue to
+edit locally.
 
 Note though, that if you do this, the revision numbers in the RCS
 master no longer correspond to those of CVS in a meaningful way.
 Technically, this is not a problem, but it might be more difficult for
 you to keep track of what is in the repository and what is not.  So we
 suggest that, frequently, you commit your changes back to CVS
-completely using @kbd{C-u C-x v v cvs RET}.
+completely using @kbd{C-u C-x v v cvs @key{RET}}.
 
 @node Snapshots
 @subsection Snapshots
@@ -2172,9 +2183,8 @@
 @noindent
 You can then edit the new change log entry further as you wish.
 
-  Unfortunately, timestamps in ChangeLog files are only dates, so some
-of the new change log entry may duplicate what's already in ChangeLog.
-You will have to remove these duplicates by hand.
+  Some of the new change log entry may duplicate what's already in
+ChangeLog.  You will have to remove these duplicates by hand.
 
   Normally, the log entry for file @file{foo} is displayed as @samp{*
 foo: @var{text of log entry}}.  The @samp{:} after @file{foo} is omitted
@@ -2391,10 +2401,9 @@
 the first time, @pxref{Registering} for details.
 
 @menu
-* General VC Options::  Options not specific for any back end system.
-* RCS Options::         Options for RCS.
+* General VC Options::  Options that apply to multiple back ends.
+* RCS and SCCS::        Options for RCS and SCCS.
 * CVS Options::         Options for CVS.
-* SCCS Options::        Options for SCCS.
 @end menu
 
 @node General VC Options
@@ -2443,12 +2452,13 @@
 
 @vindex vc-path
   You can specify additional directories to search for version control
-programs by setting the variable @code{vc-path}.  These directories are
-searched before the usual search path.  But the proper files are usually
-found automatically.
-
-@node RCS Options
-@subsubsection Options specific for RCS
+programs by setting the variable @code{vc-path}.  These directories
+are searched before the usual search path.  It is rarely necessary to
+set this variable, because VC normally finds the proper files
+automatically.
+
+@node RCS and SCCS
+@subsubsection Options for RCS and SCCS
 
 @cindex non-strict locking (RCS)
 @cindex locking, non-strict (RCS)
@@ -2456,10 +2466,10 @@
 users, but there is a mode called @dfn{non-strict locking} in which
 you can check-in changes without locking the file first.  Use
 @samp{rcs -U} to switch to non-strict locking for a particular file,
-see the @samp{rcs(1)} manpage for details.
-
-  When deducing the version control state of a file, VC first looks
-for an RCS version header string in the file (@pxref{Version
+see the @code{rcs} manpage for details.
+
+  When deducing the version control state of an RCS file, VC first
+looks for an RCS version header string in the file (@pxref{Version
 Headers}).  If there is no header string, VC normally looks at the
 file permissions of the work file; this is fast.  But there might be
 situations when the file permissions cannot be trusted.  In this case
@@ -2471,8 +2481,8 @@
 @vindex vc-consult-headers
   You can tell VC not to use version headers to determine the file
 status by setting @code{vc-consult-headers} to @code{nil}.  VC then
-always uses the file permissions (if it can trust them), or else
-checks the master file.
+always uses the file permissions (if it is supposed to trust them), or
+else checks the master file.
 
 @vindex vc-mistrust-permissions
   You can specify the criterion for whether to trust the file
@@ -2486,6 +2496,11 @@
 changed erroneously, set @code{vc-mistrust-permissions} to @code{t}.
 Then VC always checks the master file to determine the file's status.
 
+  VC determines the version control state of files under SCCS much as
+with RCS.  It does not consider SCCS version headers, though.  Thus,
+the variable @var{vc-mistrust-permissions} affects SCCS use, but
+@var{vc-consult-headers} does not.
+
 @node CVS Options
 @subsubsection Options specific for CVS
 
@@ -2496,14 +2511,15 @@
 locking.
 
 @cindex CVSREAD environment variable (CVS)
-  For one thing, you can set the @env{CVSREAD} environment variable to
-an arbitrary value.  If this variable is defined, CVS makes your work
-files read-only by default.  In Emacs, you must type @kbd{C-x C-q} to
-make the file writeable, so that editing works in fact similar as if
-locking was used.  Note however, that no actual locking is performed, so
-several users can make their files writeable at the same time.  When
-setting @env{CVSREAD} for the first time, make sure to check out all
-your modules anew, so that the file protections are set correctly.
+  For one thing, you can set the @env{CVSREAD} environment variable
+(the value you use makes no difference).  If this variable is defined,
+CVS makes your work files read-only by default.  In Emacs, you must
+type @kbd{C-x C-q} to make the file writeable, so that editing works
+in fact similar as if locking was used.  Note however, that no actual
+locking is performed, so several users can make their files writeable
+at the same time.  When setting @env{CVSREAD} for the first time, make
+sure to check out all your modules anew, so that the file protections
+are set correctly.
 
 @cindex cvs watch feature
 @cindex watching files (CVS)
@@ -2526,7 +2542,7 @@
 else has already checked in other changes to the file, you are not
 notified of it until you actually try to commit.  (But you can try to
 pick up any recent changes from the repository first, using @kbd{C-x v m
-RET}, @pxref{Merging}).
+@key{RET}}, @pxref{Merging}).
 
   When @var{vc-cvs-stay-local} is @code{t}, VC also makes local
 version backups, so that simple diff and revert operations are
@@ -2537,18 +2553,9 @@
 do in @code{vc-next-action} (@kbd{C-x v v}), just as it does for local
 repositories.  It also does not make any version backups.
 
-  You can also set @var{vc-cvs-stay-local} to a regexp that is matched
-against the repository hostname; VC then stays local only for
-repositories from hosts that match the pattern.
-
-@node SCCS Options
-@subsubsection Options specific for SCCS
-
-VC determines the version control state of files under SCCS similar as
-under RCS.  It does not consider SCCS version headers, though.  Thus,
-the variable @var{vc-mistrust-permissions} is used in the same way as
-under RCS, @pxref{RCS Options} for details.
-
+  You can also set @var{vc-cvs-stay-local} to a regular expression
+that is matched against the repository hostname; VC then stays local
+only for repositories from hosts that match the pattern.
 
 @node Directories
 @section File Directories
@@ -2789,7 +2796,7 @@
 Tar mode is used also for compressed archives---files with extensions
 @samp{.tgz}, @code{.tar.Z} and @code{.tar.gz}.
 
-  The keys @kbd{e}, @kbd{f} and @kbd{RET} all extract a component file
+  The keys @kbd{e}, @kbd{f} and @key{RET} all extract a component file
 into its own buffer.  You can edit it there and when you save the buffer
 the edited version will replace the version in the Tar buffer.  @kbd{v}
 extracts a file into a buffer in View mode.  @kbd{o} extracts the file