Merge from emacs--devo--0

Patches applied:

 * emacs--devo--0  (patch 880-885)

   - Remove RCS keywords from doc/misc/cc-mode.texi
   - Update from CVS

Revision: emacs@sv.gnu.org/emacs--unicode--0--patch-264

10 files changed, 355 insertions, 252 deletions

diff --git a/doc/emacs/ChangeLog b/doc/emacs/ChangeLog
index 41decab74bf..279a9a47ec3 100644
--- a/doc/emacs/ChangeLog
+++ b/doc/emacs/ChangeLog
@@ -1,6 +1,26 @@
+2007-10-13  Glenn Morris  <rgm@gnu.org>
+
+        * misc.texi (Interactive Shell): Correct INSIDE_EMACS reference.
+
+2007-10-11  Eric S. Raymond  <esr@snark.thyrsus.com>
+
+        * emacs.texi:
+        * files.texi (Version Systems): Minor fixes to version-control material
+        suggseted by RMS and Robert J. Chassell.
+
+2007-10-10  Eric S. Raymond  <esr@snark.thyrsus.com>
+
+        * files.texi (Version Systems):
+        * vc-xtra.texi:
+        * vc1-xtra.texi:
+        * vc2-xtra.texi: Merge in changes for new VC with fileset-oriented
+        operations.  Change of terminology from 'version' to `revision'.
+        Revise text for adequate description of VCSes with monotonic IDs.
+        * emacs.texi: Change of terminology from 'version' to `revision'.
+
 2007-10-09  Eric S. Raymond  <esr@snark.thyrsus.com>
 
-        * files.texi (Version Systems): Describe newerte VCses.
+        * files.texi (Version Systems): Describe newer VCses.
         Reorder the descriptions to be chronological.
 
 2007-10-04  Nick Roberts  <nickrob@snap.net.nz>
diff --git a/doc/emacs/emacs.texi b/doc/emacs/emacs.texi
index 96cf365497d..119e2ea80d1 100644
--- a/doc/emacs/emacs.texi
+++ b/doc/emacs/emacs.texi
@@ -460,7 +460,7 @@ Version Control
 * Introduction to VC::  How version control works in general.
 * VC Mode Line::        How the mode line shows version control status.
 * Basic VC Editing::    How to edit a file under version control.
-* Old Versions::        Examining and comparing old versions.
+* Old Revisions::       Examining and comparing old revisions of files.
 * Secondary VC Commands:: The commands used a little less frequently.
 * Branches::            Multiple lines of development.
 * Remote Repositories:: Efficient access to remote CVS servers.
diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 6e90cff5776..78c72dac330 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -1213,11 +1213,10 @@ description of what was changed in that version.
   The Emacs version control interface is called VC.  Its commands work
 with different version control systems---currently, it supports CVS,
 GNU Arch, RCS, Meta-CVS, Subversion, and SCCS.  Of these, the GNU
-project distributes CVS, GNU Arch, and RCS; we recommend that you use
-either CVS or GNU Arch for your projects, and RCS for individual
-files.  We also have free software to replace SCCS, known as CSSC; if
-you are using SCCS and don't want to make the incompatible change to
-RCS or CVS, you can switch to CSSC.
+project distributes CVS, GNU Arch, and RCS.  We also have free
+software to replace SCCS, known as CSSC; if you are using SCCS and
+don't want to make the incompatible change to RCS or CVS, you can
+switch to CSSC.
 
   VC is enabled by default in Emacs.  To disable it, set the
 customizable variable @code{vc-handled-backends} to @code{nil}
@@ -1233,7 +1232,7 @@ customizable variable @code{vc-handled-backends} to @code{nil}
 * Introduction to VC::  How version control works in general.
 * VC Mode Line::        How the mode line shows version control status.
 * Basic VC Editing::    How to edit a file under version control.
-* Old Versions::        Examining and comparing old versions.
+* Old Revisions::       Examining and comparing old versions.
 * Secondary VC Commands::    The commands used a little less frequently.
 * Branches::            Multiple lines of development.
 @ifnottex
@@ -1250,7 +1249,7 @@ customizable variable @code{vc-handled-backends} to @code{nil}
   VC allows you to use a version control system from within Emacs,
 integrating the version control operations smoothly with editing.
 Though VC cannot completely bridge the gaps between version-control
-systems with widely differing capabilities,  it does provide
+systems with widely differing capabilities, it does provide
 a uniform interface to many version control operations. Regardless of
 which version control system is in use, you will be able to do basic
 operations in much the same way.
@@ -1261,10 +1260,10 @@ this section if you are already familiar with the version control system
 you want to use.
 
 @menu
-* Why Version Control?:: Understanding the problems it addresses
-* Version Systems::  Supported version control back-end systems.
-* VC Concepts::      Words and concepts related to version control.
-* Types of Log File::    The per-file VC log in contrast to the ChangeLog.
+* Why Version Control?::    Understanding the problems it addresses
+* Version Control Systems:: Supported version control back-end systems.
+* VCS Concepts::            Words and concepts related to version control.
+* Types of Log File::       The VCS log in contrast to the ChangeLog.
 @end menu
 
 @node Why Version Control?
@@ -1287,7 +1286,7 @@ change to it.  Even for a programmer working solo change histories
 are an important aid to memory; for a multi-person project they 
 become a vitally important form of communication among developers.
 
-@node Version Systems
+@node Version Control Systems
 @subsubsection Supported Version Control Systems
 
 @cindex back end (version control)
@@ -1368,11 +1367,11 @@ be done from the command line.
 @cindex Mercurial
   Mercurial is a distributed version-control systems broadly
 resembling GNU Arch and git, with atomic fileset commits and
-rename/move histories.  Like git it is fully decventralized.
+rename/move histories.  Like git it is fully decentralized.
 VC fully supports Mercurial, except for repository sync operations
 which still need to be done from the command line.
 
-@node VC Concepts
+@node VCS Concepts
 @subsubsection Concepts of Version Control
 
 @cindex repository
@@ -1387,11 +1386,22 @@ revision.
 
 @cindex work file
 @cindex checking out files
-  A file checked out of a version-control repository is sometimes called
-the @dfn{work file}.  You edit the work file and make changes in it, as
-you would with an ordinary file.  After you are done with a set of
-changes, you @dfn{check the file in}, which records the changes in the
-repository, along with a log entry for them.
+  A file checked out of a version-control repository is sometimes
+called the @dfn{work file}.  You edit the work file and make changes
+in it, as you would with an ordinary file.  After you are done with a
+set of changes, you @dfn{check in} or @dfn{commit} the file, which
+records the changes in the repository, along with a log entry for
+them.
+
+@cindex revision
+@cindex revision ID
+  A copy of a file stored in a repository is called a @dfn{revision}.
+The history of a file is a sequence of revisions.  Each revisions is
+named by a @dfn{revision ID}.  In older VCSes (such as SCCS and RCS),
+the simplest kind of revision ID consisted of a @dfn{dot-pair};
+integers (the @dfn{major} and @dfn{minor} revisions) separated by a
+dot.  Newer VCSes tend to use @dfn{monotonic} revision IDs that are
+simple integers counting from 1.
 
   To go beyond these basic concepts, you will need to understand three
 ways in which version-control systems can differ from each other.  They
@@ -1417,7 +1427,7 @@ the file, making the work file read-only again.  This allows other users
 to lock the file to make further changes.
 
   By contrast, a merging system lets each user check out and modify a
-work file at any time.  When you check in a a file, the system will
+work file at any time.  When you check in a file, the system will
 attempt to merge your changes with any others checked into the
 repository since you checked out the file.
 
@@ -1429,14 +1439,15 @@ happen when you check in a change to a file that conflicts with a change
 checked in by someone else after your checkout.  Both kinds of conflict
 have to be resolved by human judgment and communication.
 
-  SCCS always uses locking. RCS is lock-based by default but can be told
-to operate in a merging style.  CVS is merge-based by default but can
-be told to operate in a locking mode.  Most later version-control
-systems, such as Subversion and GNU Arch, have been fundamentally
-merging-based rather than locking-based.  This is because experience
-has shown that the merging-based approach is generally superior to
-the locking one, both in convenience to developers and in minimizing
-the number and severity of conflicts that actually occur.
+  SCCS always uses locking. RCS is lock-based by default but can be
+told to operate in a merging style.  CVS and Subversion are
+merge-based by default but can be told to operate in a locking mode.
+Most later version-control systems, such as GNU Arch, git, and
+Mercurial, have been based exclusively on merging rather than locking.
+This is because experience has shown that the merging-based approach
+is generally superior to the locking one, both in convenience to
+developers and in minimizing the number and severity of conflicts that
+actually occur.
 
    While it is rather unlikely that anyone will ever again build a
 fundamentally locking-based rather than merging-based version-control
@@ -1448,14 +1459,14 @@ both locking and merging version control and tries to hide the differences
 between them as much as possible.
 
 @cindex files versus changesets.
-  On SCCS. RCS, CVS, and other early version-control systems, checkins
+  On SCCS, RCS, CVS, and other early version-control systems, checkins
 and other operations are @dfn{file-based}; each file has its own
-@dfn{master file} with its own comment- and revision history separate
+@dfn{master file} with its own comment and revision history separate
 from that of all other files in the system.  Later systems, beginning
-with Subversion, are @dfn{changeset-based}; a checkin may include
-changes to several files and that change set is treated as a unit by the
-system.  Any comment associated with the change doesn't belong to any
-one file, but is attached to the changeset itself.
+with Subversion, became @dfn{changeset-based}; a checkin under these
+may include changes to several files and that change set is treated as
+a unit by the system.  Any comment associated with the change belongs
+to no single file, but is attached to the changeset itself.
 
   Changeset-based version control is in general both more flexible and
 more powerful than file-based version control; usually, when a change to
@@ -1465,22 +1476,30 @@ figure that out, and while file-based systems are passing out of use
 there are lots of legacy repositories still to be dealt with at time of
 writing in 2007.
 
-@cindex centralized vs. decentralized
+  In fact, older versions of VC mode supported only file-based systems,
+leading to some unhappy results when it was used to drive
+changeset-based ones---the Subversion support, for example, used to break
+up changesets into multiple per-file commits.  This has been fixed, but
+it has left a legacy in VC-mode's terminology.  The terms ``checkin'' 
+and ``checkout'' are associated with file-based and locking-based
+systems and a bit archaic; nowadays those operations are usually called
+``commit'' and ``update''.
 
+@cindex centralized vs. decentralized
   Early version-control systems were designed around a @dfn{centralized}
 model in which each project has only one repository used by all
 developers.  SCCS, RCS, CVS, and Subversion share this kind of model.
 It has two important problems. One is that a single repository is a
-single point of failure--if the repository server is down all work
+single point of failure---if the repository server is down all work
 stops.  The other is that you need to be connected live to the server to
 do checkins and checkouts; if you're offline, you can't work.
 
-  Newer version-control systems like GNU Arch are @dfn{decentralized}.
-A project may have several different repositories, and these systems
-support a sort of super-merge between repositories that tries to
-reconcile their change histories.  At the limit, each developer has
-his/her own repository, and repository merges replace checkin/commit
-operations.
+  Newer version-control systems like GNU Arch, git, Mercurial, and Bzr
+are @dfn{decentralized}.  A project may have several different
+repositories, and these systems support a sort of super-merge between
+repositories that tries to reconcile their change histories.  At the
+limit, each developer has his/her own repository, and repository
+merges replace checkin/commit operations.
 
   VC's job is to help you manage the traffic between your personal
 workfiles and a repository.  Whether that repository is a single master
@@ -1553,7 +1572,7 @@ to copy it to @file{ChangeLog}
 this on the mode line.  For example, @samp{RCS-1.3} says that RCS is
 used for that file, and the current version is 1.3.
 
-  The character between the back-end name and the version number
+  The character between the back-end name and the revision ID
 indicates the version control status of the file.  @samp{-} means that
 the work file is not locked (if locking is in use), or not modified (if
 locking is not in use).  @samp{:} indicates that the file is locked, or
@@ -1575,8 +1594,56 @@ system, but is usually not excessive.
 @node Basic VC Editing
 @subsection Basic Editing under Version Control
 
+@menu
+* Selecting a fileset::          Choosing a set of files to operate on 
+* Doing the next logical thing:: Stepping forward in the development cycle
+* VC with a locking VCS::     RCS in its default mode, SCCS, and optionally CVS.
+* VC with a merging VCS::     Without locking: default mode for CVS.
+* Advanced C-x v v::    Advanced features available with a prefix argument.
+* Log Buffer::          Features available in log entry buffers.
+@end menu
+
+@node Selecting a fileset
+@subsubsection Choosing the scope of your command
+
+@cindex filesets
+   Most VC commands operate on @dfn{filesets}.  A fileset is a 
+group of files that you have chosen to treat as a unit at the
+time you perform the command.  Filesets are the way that VC
+mode bridges the gap between file-based and changeset-based 
+version-control systems.
+
+   If you are visiting a version-controlled file in the current buffer,
+the default fileset for any command is simply that one file.  If you
+are visiting a VC Dired buffer, and some files in it are marked,
+your fileset is the marked files only.
+
+   All files in a fileset must be under the same version-control system.
+If they are not, VC mode will fail when you attempt to execute 
+a command on the fileset.
+
+   In VC, filesets, are, essentially, a way to pass multiple file
+arguments as a group to underlying version-control commands.  For
+example, on Subversion a checkin with more than one file in its
+fileset will become a joint commit, as though you had typed
+@command{svn commit} with those file arguments at the shell command
+line in the directory of the selected buffer.
+
+   If you are accustomed to earlier versions of VC, the change in behavior
+you will notice is in VC-Dired mode. Other than @kbd{C-x v v}, most
+VC-mode commands once operated on only one file selected by the line
+the cursor is on.  The change in the behavior of @kbd{C-x v v} outside
+VC-Dired mode is more subtle.  Formerly it operated in parallel on all
+marked files, but did not pass them to the version-control backends as
+a group.  Now it does, which enables VC to drive changeset-based
+version-control systems.
+
+@node Doing the next logical thing
+@subsubsection Performing the next operation in the development cycle
+
   The principal VC command is an all-purpose command that performs
-either locking or check-in, depending on the situation.
+either locking or check-in on your current fileset, depending on 
+the situation.
 
 @table @kbd
 @itemx C-x v v
@@ -1600,14 +1667,7 @@ accidentally edit a file without properly checking it out first.  To
 achieve this, bind the key @kbd{C-x C-q} to @kbd{vc-toggle-read-only}
 in your @file{~/.emacs} file.  (@xref{Init Rebinding}.)
 
-@menu
-* VC with Locking::     RCS in its default mode, SCCS, and optionally CVS.
-* Without Locking::     Without locking: default mode for CVS.
-* Advanced C-x v v::    Advanced features available with a prefix argument.
-* Log Buffer::          Features available in log entry buffers.
-@end menu
-
-@node VC with Locking
+@node VC with a locking VCS
 @subsubsection Basic Version Control with Locking
 
   If locking is used for the file (as with SCCS, and RCS in its default
@@ -1621,7 +1681,7 @@ makes it writable so that you can change it.
 @item
 If the file is locked by you, and contains changes, @kbd{C-x v v} checks
 in the changes.  In order to do this, it first reads the log entry
-for the new version.  @xref{Log Buffer}.
+for the new revision.  @xref{Log Buffer}.
 
 @item
 If the file is locked by you, but you have not changed it since you
@@ -1638,18 +1698,19 @@ formerly locked the file, to inform him of what has happened.
   These rules also apply when you use CVS in locking mode, except
 that there is no such thing as stealing a lock.
 
-@node Without Locking
-@subsubsection Basic Version Control without Locking
+@node VC with a merging VCS
+@subsubsection Basic Version Control with Merging
 
   When your version-control system is merging-based rather than
 locking-based---the default for CVS and Subversion, and the way GNU
-Arch always works---work files are always writable; you do not need to
-do anything before you begin to edit a file.  The status indicator on
-the mode line is @samp{-} if the file is unmodified; it flips to
-@samp{:} as soon as you save any changes in the work file.
+Arch and more modern systems always work---work files are always
+writable; you do not need to do anything before you begin to edit a
+file.  The status indicator on the mode line is @samp{-} if the file
+is unmodified; it flips to @samp{:} as soon as you save any changes in
+the work file.
 
   Here is what @kbd{C-x v v} does when using a merging-based system
-(such as CVS or Subversion in their defaiult merging mode):
+(such as CVS or Subversion in their default merging mode):
 
 @itemize @bullet
 @item
@@ -1663,7 +1724,7 @@ to commit your own changes, type @kbd{C-x v m @key{RET}}.)
 @item
 If there are no new changes in the repository, but you have made
 modifications in your work file, @kbd{C-x v v} checks in your changes.
-In order to do this, it first reads the log entry for the new version.
+In order to do this, it first reads the log entry for the new revision.
 @xref{Log Buffer}.
 
 @item
@@ -1675,9 +1736,9 @@ require locking, except that automatic merging of changes from the
 repository is not implemented.  Unfortunately, this means that nothing
 informs you if another user has checked in changes in the same file
 since you began editing it, and when this happens, his changes will be
-effectively removed when you check in your version (though they will
+effectively removed when you check in your revision (though they will
 remain in the repository, so they will not be entirely lost).  You must
-therefore verify that the current version is unchanged, before you
+therefore verify that the current revision is unchanged, before you
 check in your changes.
 
   In addition, locking is possible with RCS even in this mode, although
@@ -1690,7 +1751,7 @@ changes in the repository automatically and notify you when they occur.
 @node Advanced C-x v v
 @subsubsection Advanced Control in @kbd{C-x v v}
 
-@cindex version number to check in/out
+@cindex revision ID to check in/out
   When you give a prefix argument to @code{vc-next-action} (@kbd{C-u
 C-x v v}), it still performs the next logical version control
 operation, but accepts additional arguments to specify precisely how
@@ -1698,21 +1759,21 @@ to do the operation.
 
 @itemize @bullet
 @item
-If the file is modified (or locked), you can specify the version
-number to use for the new version that you check in.  This is one way
+If the file is modified (or locked), you can specify the revision ID
+to use for the new version 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
-v v @key{RET}} is a convenient way to get the latest version of a file from
-the repository.
+revision to select; this lets you start working from an older
+revision, or on another branch.  If you do not enter any revision,
+that takes you to the highest (``head'') revision on the current
+branch; therefore @kbd{C-u C-x v v @key{RET}} is a convenient way to
+get the latest version of a file from the repository.
 
 @item
 @cindex specific version control system
-Instead of the version number, you can also specify the name of a
+Instead of the revision ID, 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
 @iftex
@@ -1776,11 +1837,13 @@ in the @samp{*VC-Log*} buffer, and you can go back to that buffer at any
 time to complete the check-in.
 
   If you change several source files for the same reason, it is often
-convenient to specify the same log entry for many of the files.  To do
-this, use the history of previous log entries.  The commands @kbd{M-n},
-@kbd{M-p}, @kbd{M-s} and @kbd{M-r} for doing this work just like the
-minibuffer history commands (except that these versions are used outside
-the minibuffer).
+convenient to specify the same log entry for many of the files.  (This
+is the normal way to do things on a changeset-oriented system, where
+comments are attached to changesets rather than the history of
+individual files.) The most convenient way to do this is to mark all the
+files in VC-Dired mode and check in from there; the log buffer will
+carry the fileset information with it and do a group commit when you
+confirm it with @kbd{C-c C-c}.
 
   However, you can also browse the history of previous log entries to
 duplicate a checkin comment. This can be useful when you want several
@@ -1794,62 +1857,73 @@ these versions are used outside the minibuffer).
 mode, which involves running two hooks: @code{text-mode-hook} and
 @code{vc-log-mode-hook}.  @xref{Hooks}.
 
-@node Old Versions
-@subsection Examining And Comparing Old Versions
+@node Old Revisions
+@subsection Examining And Comparing Old Revisions
 
   One of the convenient features of version control is the ability
-to examine any version of a file, or compare two versions.
+to examine any revision of a file, or compare two revisions.
 
 @table @kbd
-@item C-x v ~ @var{version} @key{RET}
-Examine version @var{version} of the visited file, in a buffer of its
+@item C-x v ~ @var{revision} @key{RET}
+Examine revision @var{revision} of the visited file, in a buffer of its
 own.
 
 @item C-x v =
-Compare the current buffer contents with the focus version from which
-you started editing.
+Compare the buffer contents associated with the current
+fileset with the working revision(s) from which you started editing.
 
-@item C-u C-x v = @var{file} @key{RET} @var{oldvers} @key{RET} @var{newvers} @key{RET}
-Compare the specified two versions of @var{file}.
+@item C-u C-x v = @key{RET} @var{oldvers} @key{RET} @var{newvers} @key{RET}
+Compare the specified two repository revisions of the current fileset.
 
 @item C-x v g
-Display the file with per-line version information and using colors.
+Display the file with per-line revision information and using colors.
 @end table
 
-@findex vc-version-other-window
+@findex vc-revision-other-window
 @kindex C-x v ~
-  To examine an old version in its entirety, visit the file and then type
-@kbd{C-x v ~ @var{version} @key{RET}} (@code{vc-version-other-window}).
-This puts the text of version @var{version} in a file named
-@file{@var{filename}.~@var{version}~}, and visits it in its own buffer
-in a separate window.  (In RCS, you can also select an old version
+  To examine an old revision in its entirety, visit the file and then type
+@kbd{C-x v ~ @var{revision} @key{RET}} (@code{vc-revision-other-window}).
+This puts the text of revision @var{revision} in a file named
+@file{@var{filename}.~@var{revision}~}, and visits it in its own buffer
+in a separate window.  (In RCS, you can also select an old revision
 and create a branch from it.  @xref{Branches}.)
 
 @findex vc-diff
 @kindex C-x v =
-  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 master version from which you started editing the
-file (this is not necessarily the latest 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
+@kbd{C-x v =} compares the current buffer contents of each file in the
+current fileset (saving them in the file if necessary) with the
+repository revision from which you started editing each file (this is not
+necessarily the latest revision of the file).  The diff will be displayed
+in a special buffer in another window.
+
+@findex vc-diff
+@kindex C-u C-x v =
+  You can compare two repository revisions of the current fileset with
+the command @kbd{C-u C-x v =} (@code{vc-diff}).  @kbd{C-u C-x v =} reads
+two revision ID or tags. The diff will be displayed in a special
+buffer in another window.
+
+  You can specify a checked-in revision by its ID; 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
+from all the checked-in revisions).  You can also specify a snapshot name
 @iftex
 (@pxref{Snapshots,,,emacs-xtra, Specialized Emacs Features})
 @end iftex
 @ifnottex
 (@pxref{Snapshots})
 @end ifnottex
-instead of one or both version numbers.
+instead of one or both revision ID.
 
-  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.
+  Note that if your version-control system is file-oriented (SCCS,
+RCS, CVS) rather than fileset-oriented (Subversion, GNU Arch, git,
+Mercurial) specifying a revision of a multiple-file fileset by
+revision ID (as opposed to a snapshot name or RSCCS/RCS tag) is
+unlikely to return diffs that are connected in any meaningful way.
+
+  If you invoke @kbd{C-u C-x v =} or @kbd{C-u C-x v =} from a buffer
+that is neither visiting a version-controlled file nor a VC Dired
+buffer, these commands will generate a diff of all registered files in
+the current directory and its subdirectories.
 
 @vindex vc-diff-switches
 @vindex vc-rcs-diff-switches
@@ -1867,12 +1941,12 @@ the options in @code{vc-rcs-diff-switches}.  The
 Compilation mode (@pxref{Compilation Mode}), such as @kbd{C-x `} and
 @kbd{C-c C-c}, in both the ``old'' and ``new'' text, and they always
 find the corresponding locations in the current work file.  (Older
-versions are not, in general, present as files on your disk.)
+revisions are not, in general, present as files on your disk.)
 
 @findex vc-annotate
 @kindex C-x v g
   For some back ends, you can display the file @dfn{annotated} with
-per-line version information and using colors to enhance the visual
+per-line revision information and using colors to enhance the visual
 appearance, with the command @kbd{M-x vc-annotate}.  It creates a new
 buffer (the ``annotate buffer'') displaying the file's text, with each
 part colored to show how old it is.  Text colored red is new, blue means
@@ -1881,7 +1955,7 @@ the color is scaled over the full range of ages, such that the oldest
 changes are blue, and the newest changes are red.
 
   When you give a prefix argument to this command, it uses the
-minibuffer to read two arguments: which version number to display and
+minibuffer to read two arguments: the ID of which revision to display and
 annotate (instead of the current file contents), and the time span in
 days the color range should cover.  
 
@@ -1919,9 +1993,9 @@ the author's description of the changes in the revision on the current
 line.
 
 @item W
-Annotate the focus version--the one you are editing.  If you used
+Annotate the working revision--the one you are editing.  If you used
 @kbd{P} and @kbd{N} to browse to other revisions, use this key to
-return to your current version.
+return to your working revision.
 @end table
 
 @node Secondary VC Commands
@@ -1974,16 +2048,18 @@ situation.
   If locking is in use, @kbd{C-x v i} leaves the file unlocked and
 read-only.  Type @kbd{C-x v v} if you wish to start editing it.  After
 registering a file with CVS, you must subsequently commit the initial
-version by typing @kbd{C-x v v}.  Until you do that, the version
+revision by typing @kbd{C-x v v}.  Until you do that, the revision ID
 appears as @samp{@@@@} in the mode line.
 
-@vindex vc-default-init-version
-@cindex initial version number to register
-  The initial version number for a newly registered file is 1.1, by
-default.  You can specify a different default by setting the variable
-@code{vc-default-init-version}, or you can give @kbd{C-x v i} a numeric
-argument; then it reads the initial version number for this particular
-file using the minibuffer.
+@vindex vc-default-init-revision
+@cindex initial revision ID to register
+  The default initial revision ID for a newly registered file
+varies by what VCS you are using; normally it will be 1.1 on VCSes
+that use dot-pair revision IDs and 1 on VCSes that use monotonic IDs.
+You can specify a different default by setting the variable
+@code{vc-default-init-revision}, or you can give @kbd{C-x v i} a
+numeric argument; then it reads the initial revision ID for this
+particular file using the minibuffer.
 
 @vindex vc-initial-comment
   If @code{vc-initial-comment} is non-@code{nil}, @kbd{C-x v i} reads an
@@ -1995,12 +2071,12 @@ the initial comment works like reading a log entry (@pxref{Log Buffer}).
 
 @table @kbd
 @item C-x v l
-Display version control state and change history.
+Display revision control state and change history.
 @end table
 
 @kindex C-x v l
 @findex vc-print-log
-  To view the detailed version control status and history of a file,
+  To view the detailed revision control status and history of a file,
 type @kbd{C-x v l} (@code{vc-print-log}).  It displays the history of
 changes to the current file, including the text of the log entries.  The
 output appears in a separate window.  The point is centered at the
@@ -2048,7 +2124,7 @@ It also takes a numeric prefix argument as a repeat count.
 
 @item f
 Visit the revision indicated at the current line, like typing @kbd{C-x
-v ~} and specifying this revision's number (@pxref{Old Versions}).
+v ~} and specifying this revision's ID (@pxref{Old Revisions}).
 
 @item d
 Display the diff (@pxref{Comparing Files}) between the revision
@@ -2062,7 +2138,7 @@ current line was committed.
 
 @table @kbd
 @item C-x v u
-Revert the buffer and the file to the version from which you started
+Revert the buffer and the file to the working revision from which you started
 editing the file.
 
 @item C-x v c
@@ -2073,51 +2149,25 @@ This undoes your last check-in.
 @kindex C-x v u
 @findex vc-revert-buffer
   If you want to discard your current set of changes and revert to the
-version from which you started editing the file, use @kbd{C-x v u}
+working revision from which you started editing the file, use @kbd{C-x v u}
 (@code{vc-revert-buffer}).  This leaves the file unlocked; if locking
 is in use, you must first lock the file again before you change it
 again.  @kbd{C-x v u} requires confirmation, unless it sees that you
-haven't made any changes with respect to the master version.
+haven't made any changes with respect to the master copy of the
+working revision.
 
   @kbd{C-x v u} is also the command to unlock a file if you lock it and
 then decide not to change it.
 
 @kindex C-x v c
-@findex vc-cancel-version
+@findex vc-rollback
   To cancel a change that you already checked in, use @kbd{C-x v c}
-(@code{vc-cancel-version}).  This command discards all record of the
-most recent checked-in version, but only if your work file corresponds
-to that version---you cannot use @kbd{C-x v c} to cancel a version
-that is not the latest on its branch.  @kbd{C-x v c} also offers to
-revert your work file and buffer to the previous version (the one that
-precedes the version that is deleted).
-
-  If you answer @kbd{no}, VC keeps your changes in the buffer, and locks
-the file.  The no-revert option is useful when you have checked in a
-change and then discover a trivial error in it; you can cancel the
-erroneous check-in, fix the error, and check the file in again.
-
-  When @kbd{C-x v c} does not revert the buffer, it unexpands all
-version control headers in the buffer instead
-@iftex
-(@pxref{Version Headers,,,emacs-xtra, Specialized Emacs Features}).
-@end iftex
-@ifnottex
-(@pxref{Version Headers}).
-@end ifnottex
-This is because the buffer no longer corresponds to any existing
-version.  If you check it in again, the check-in process will expand
-the headers properly for the new version number.
-
-  However, it is impossible to unexpand the RCS @samp{@w{$}Log$} header
-automatically.  If you use that header feature, you have to unexpand it
-by hand---by deleting the entry for the version that you just canceled.
-
-  Be careful when invoking @kbd{C-x v c}, as it is easy to lose a lot of
-work with it.  To help you be careful, this command always requires
-confirmation with @kbd{yes}.  Note also that this command is disabled
-under CVS, because canceling versions is very dangerous and discouraged
-with CVS.
+(@code{vc-rollback}).  This command discards all record of the most
+recent checked-in revision, but only if your work file corresponds to
+that revision---you cannot use @kbd{C-x v c} to cancel a revision that is
+not the latest on its branch.  Note that many version-control systems do
+not support rollback at all; this command is something of a historical 
+relic.
 
 @ifnottex
 @c vc1-xtra.texi needs extra level of lowering.
@@ -2132,7 +2182,7 @@ with CVS.
 @cindex trunk (version control)
 
   One use of version control is to maintain multiple ``current''
-versions of a file.  For example, you might have different versions of a
+revisions of a file.  For example, you might have different revisions of a
 program in which you are gradually adding various unfinished new
 features.  Each such independent line of development is called a
 @dfn{branch}.  VC allows you to create branches, switch between
@@ -2140,18 +2190,30 @@ different branches, and merge changes from one branch to another.
 Please note, however, that branches are not supported for SCCS.
 
   A file's main line of development is usually called the @dfn{trunk}.
-The versions on the trunk are normally numbered 1.1, 1.2, 1.3, etc.  At
-any such version, you can start an independent branch.  A branch
-starting at version 1.2 would have version number 1.2.1.1, and consecutive
-versions on this branch would have numbers 1.2.1.2, 1.2.1.3, 1.2.1.4,
-and so on.  If there is a second branch also starting at version 1.2, it
-would consist of versions 1.2.2.1, 1.2.2.2, 1.2.2.3, etc.
-
-@cindex head version
-  If you omit the final component of a version number, that is called a
-@dfn{branch number}.  It refers to the highest existing version on that
-branch---the @dfn{head version} of that branch.  The branches in the
-example above have branch numbers 1.2.1 and 1.2.2.
+You can create multiple branches from the trunk.  How the difference
+between trunk and branch is made visible is dependent on whether the
+VCS uses dot-pair or monotonic version IDs.
+
+  In VCSes with dot-pair revision IDs, the revisions on the trunk are
+normally IDed 1.1, 1.2, 1.3, etc.  At any such revision, you can
+start an independent branch.  A branch starting at revision 1.2 would
+have revision ID 1.2.1.1, and consecutive revisions on this branch
+would have IDs 1.2.1.2, 1.2.1.3, 1.2.1.4, and so on.  If there is
+a second branch also starting at revision 1.2, it would consist of
+revisions 1.2.2.1, 1.2.2.2, 1.2.2.3, etc.
+
+   In VCSes with monotonic revision IDs, trunk revisions are IDed as
+1, 2, 3, etc.  A branch from (say) revision 2 might start with 2.1 and
+continue through 2.2, 2.3, etc.  But naming conventions for branches
+and subbranches vary widely on these systems, and some (like
+Mercurial) never depart from the monotonic integer sequence at all.
+Consult the documentation of the VCS you are using.
+
+@cindex head revision
+  If you omit the final component of a dot-pair revision ID, that is called a
+@dfn{branch ID}.  It refers to the highest existing revision on that
+branch---the @dfn{head revision} of that branch.  The branches in the
+dot-pair example above have branch IDs 1.2.1 and 1.2.2.
 
 @menu
 * Switching Branches::    How to get to another existing branch.
@@ -2165,14 +2227,15 @@ example above have branch numbers 1.2.1 and 1.2.2.
 @subsubsection Switching between Branches
 
   To switch between branches, type @kbd{C-u C-x v v} and specify the
-version number you want to select.  On a locking-based system, this
+revision ID you want to select.  On a locking-based system, this
 version is then visited @emph{unlocked} (write-protected), so you can
 examine it before locking it.  Switching branches in this way is allowed
 only when the file is not locked.
 
-  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 @key{RET}, Emacs goes to the highest version on the trunk.
+  On a VCS with dot-pair IDs, you can omit the minor part, thus giving
+only the branch ID; this takes you to the head version on the
+chosen branch.  If you 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
@@ -2181,36 +2244,36 @@ other branch.
 @node Creating Branches
 @subsubsection Creating New Branches
 
-  To create a new branch from a head version (one that is the latest in
-the branch that contains it), first select that version if necessary,
+  To create a new branch from a head revision (one that is the latest in
+the branch that contains it), first select that revision if necessary,
 lock it with @kbd{C-x v v}, and make whatever changes you want.  Then,
 when you check in the changes, use @kbd{C-u C-x v v}.  This lets you
-specify the version number for the new version.  You should specify a
-suitable branch number for a branch starting at the current version.
-For example, if the current version is 2.5, the branch number should be
+specify the revision ID for the new revision.  You should specify a
+suitable branch ID for a branch starting at the current revision.
+For example, if the current revision is 2.5, the branch ID should be
 2.5.1, 2.5.2, and so on, depending on the number of existing branches at
 that point.
 
-  To create a new branch at an older version (one that is no longer the
-head of a branch), first select that version (@pxref{Switching
+  To create a new branch at an older revision (one that is no longer the
+head of a branch), first select that revision (@pxref{Switching
 Branches}).  Your procedure will then differ depending on whether you
 are using a locking or merging-based VCS.
 
-  On a locking VCS, you will need to lock the old version branch with
+  On a locking VCS, you will need to lock the old revision branch with
 @kbd{C-x v v}.  You'll be asked to confirm, when you lock the old
-version, that you really mean to create a new branch---if you say no,
-you'll be offered a chance to lock the latest version instead.  On
+revision, that you really mean to create a new branch---if you say no,
+you'll be offered a chance to lock the latest revision instead.  On
 a merging-based VCS you will skip this step.
 
   Then make your changes and type @kbd{C-x v v} again to check in a new
-version.  This automatically creates a new branch starting from the
-selected version.  You need not specially request a new branch, because
-that's the only way to add a new version at a point that is not the head
+revision.  This automatically creates a new branch starting from the
+selected revision.  You need not specially request a new branch, because
+that's the only way to add a new revision at a point that is not the head
 of a branch.
 
   After the branch is created, you ``stay'' on it.  That means that
-subsequent check-ins create new versions on that branch.  To leave the
-branch, you must explicitly select a different version with @kbd{C-u C-x
+subsequent check-ins create new revisions on that branch.  To leave the
+branch, you must explicitly select a different revision with @kbd{C-u C-x
 v v}.  To transfer changes from one branch to another, use the merge
 command, described in the next section.
 
@@ -2240,26 +2303,26 @@ 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.
 
-  You can also enter a branch number or a pair of version numbers in
+  You can also enter a branch ID or a pair of revision IDs in
 the minibuffer.  Then @kbd{C-x v m} finds the changes from that
-branch, or the differences between the two versions you specified, and
-merges them into the current version of the current file.
+branch, or the differences between the two revisions you specified, and
+merges them into the current revision of the current file.
 
   As an example, suppose that you have finished a certain feature on
 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 v v
-@key{RET}}.  Version 1.5 is now current.  If locking is used for the file,
-type @kbd{C-x v v} to lock version 1.5 so that you can change it.  Next,
+to revision 1.5.  To merge the changes from the branch to the trunk,
+first go to the head revision of the trunk, by typing @kbd{C-u C-x v v
+@key{RET}}.  Revision 1.5 is now current.  If locking is used for the file,
+type @kbd{C-x v v} to lock revision 1.5 so that you can change it.  Next,
 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
+branch 1.3.1 (relative to revision 1.3, where the branch started, up to
+the last revision on the branch) and merges it into the current revision
 of the work file.  You can now check in the changed file, thus creating
-version 1.6 containing the changes from the branch.
+revision 1.6 containing the changes from the branch.
 
   It is possible to do further editing after merging the branch, before
 the next check-in.  But it is usually wiser to check in the merged
-version, then lock it and make the further changes.  This will keep
+revision, then lock it and make the further changes.  This will keep
 a better record of the history of changes.
 
 @cindex conflicts
@@ -2277,7 +2340,7 @@ Ediff, Ediff, ediff, The Ediff Manual}).
   If you say no, the conflicting changes are both inserted into the
 file, surrounded by @dfn{conflict markers}.  The example below shows how
 a conflict region looks; the file is called @samp{name} and the current
-master file version with user B's changes in it is 1.11.
+master file revision with user B's changes in it is 1.11.
 
 @c @w here is so CVS won't think this is a conflict.
 @smallexample
@@ -2300,12 +2363,12 @@ check in the merged version afterwards.
 @subsubsection Multi-User Branching
 
   It is often useful for multiple developers to work simultaneously on
-different branches of a file.  CVS allows this by default; for RCS, it
-is possible if you create multiple source directories.  Each source
-directory should have a link named @file{RCS} which points to a common
-directory of RCS master files.  Then each source directory can have its
-own choice of selected versions, but all share the same common RCS
-records.
+different branches of a file.  CVS and later systems allow this by
+default; for RCS, it is possible if you create multiple source
+directories.  Each source directory should have a link named
+@file{RCS} which points to a common directory of RCS master files.
+Then each source directory can have its own choice of selected
+revisions, but all share the same common RCS records.
 
   This technique works reliably and automatically, provided that the
 source files contain RCS version headers
@@ -2315,13 +2378,13 @@ source files contain RCS version headers
 @ifnottex
 (@pxref{Version Headers}).
 @end ifnottex
-The headers enable Emacs to be sure, at all times, which version
-number is present in the work file.
+The headers enable Emacs to be sure, at all times, which revision
+ID is present in the work file.
 
   If the files do not have version headers, you must instead tell Emacs
 explicitly in each session which branch you are working on.  To do this,
 first find the file, then type @kbd{C-u C-x v v} and specify the correct
-branch number.  This ensures that Emacs knows which branch it is using
+branch ID.  This ensures that Emacs knows which branch it is using
 during this particular editing session.
 
 @ifnottex
diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
index c4cdea4359d..83fc1617066 100644
--- a/doc/emacs/misc.texi
+++ b/doc/emacs/misc.texi
@@ -488,12 +488,13 @@ also change the coding system for a running subshell by typing
 Coding}.
 
 @cindex @env{INSIDE_EMACS} environment variable
-  Emacs sets the envitonment variable @env{INSIDE_EMACS} to @code{t}
-in the subshell.  Programs can check this variable to determine
-whether they are running inside an Emacs subshell.
+  Emacs sets the environment variable @env{INSIDE_EMACS} (to a
+comma-separated list including the Emacs version) in the subshell.
+Programs can check this variable to determine whether they are running
+inside an Emacs subshell.
 
 @cindex @env{EMACS} environment variable
-  Emacs also sets the @env{EMACS} environment variable to @code{t} if
+  Emacs also sets the @env{EMACS} environment variable (to @code{t}) if
 it is not already defined.  @strong{Warning:} This environment
 variable is deprecated.  Programs that check this variable should be
 changed to check @env{INSIDE_EMACS} instead.
diff --git a/doc/emacs/vc-xtra.texi b/doc/emacs/vc-xtra.texi
index 6ec69d60896..5b4e374a6ea 100644
--- a/doc/emacs/vc-xtra.texi
+++ b/doc/emacs/vc-xtra.texi
@@ -15,7 +15,7 @@ the Emacs Manual}).  This chapter describes more advanced VC usage.
 @menu
 * VC Dired Mode::       Listing files managed by version control.
 * VC Dired Commands::   Commands to use in a VC Dired buffer.
-* Remote Repositories:: Efficient access to remote CVS servers.
+* Remote Repositories:: Efficient access to remote VCS servers.
 * Snapshots::           Sets of file versions treated as a unit.
 * Miscellaneous VC::    Various other commands and features of VC.
 * Customizing VC::      Variables that change VC's behavior.
diff --git a/doc/emacs/vc1-xtra.texi b/doc/emacs/vc1-xtra.texi
index 6d5df78848c..ebdd1d5951f 100644
--- a/doc/emacs/vc1-xtra.texi
+++ b/doc/emacs/vc1-xtra.texi
@@ -120,21 +120,27 @@ ordinary Dired, that allows you to specify additional switches for the
   All the usual Dired commands work normally in VC Dired mode, except
 for @kbd{v}, which is redefined as the version control prefix.  You can
 invoke VC commands such as @code{vc-diff} and @code{vc-print-log} by
-typing @kbd{v =}, or @kbd{v l}, and so on.  Most of these commands apply
-to the file name on the current line.
+typing @kbd{v =}, or @kbd{v l}, and so on.  These commands will apply
+to the set of files you have marked for operation in the VC-Dired
+buffer.  
 
   The command @kbd{v v} (@code{vc-next-action}) operates on all the
 marked files, so that you can lock or check in several files at once.
-If it operates on more than one file, it handles each file according to
-its current state; thus, it might lock one file, but check in another
-file.  This could be confusing; it is up to you to avoid confusing
-behavior by marking a set of files that are in a similar state.  If no
-files are marked, @kbd{v v} operates on the file in the current line.
-
-  If any files call for check-in, @kbd{v v} reads a single log entry,
-then uses it for all the files being checked in.  This is convenient for
-registering or checking in several files at once, as part of the same
-change.
+If the underlying VC supports atomic commits of multiple-file
+changesets @kbd{v v} with a selected set of modified but not committed 
+files wuill commit all of them at once as a single changeset.
+
+  When @kbd{v v} (@code{vc-next-action}) operates on a set of files,
+it requires that all of those files must be in the same state;
+otherwise it will throw an error.  Note that this differs from the 
+behavior of older versions of VC, which did not have fileset
+operations and simply did @code{vc-next-action} on each file 
+individually.
+
+  If any files are in a state that calls for commit, @kbd{v v} reads a
+single log entry and uses it for the changeset as a whole.  If the
+underling VCS is file- rather than changeset-oriented, the log entry
+will be replicated into the history of each file.
 
 @findex vc-dired-toggle-terse-mode
 @findex vc-dired-mark-locked
diff --git a/doc/emacs/vc2-xtra.texi b/doc/emacs/vc2-xtra.texi
index 83f28088726..da7ef76025a 100644
--- a/doc/emacs/vc2-xtra.texi
+++ b/doc/emacs/vc2-xtra.texi
@@ -6,17 +6,24 @@
 @c printed version) or in the main Emacs manual (for the on-line version).
 @node Remote Repositories
 @subsection Remote Repositories
-@cindex remote repositories (CVS)
+@cindex remote repositories
+
+  A common way of using CVS and other more advanced VCSes is to set up
+a central 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 repository server.
 
-  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 a repository server is often slow,
+and that developers might need to work off-line as well.  While only
+third-generation decentralized VCses such as GNU Arch or Mercurial
+really solve this problem, VC is designed to reduce the amount of
+network interaction necessary.
 
-  One difficulty is that access to the CVS server is often slow, and
-that developers might need to work off-line as well.  VC is designed
-to reduce the amount of network interaction necessary.
+  If you are using a truly decentralized VCS you can skip the rest of
+this section. It describes backup and local-repository techniques
+that are only useful for Subversion and earlier VCSes.
 
 @menu
 * Version Backups::        Keeping local copies of repository versions.
@@ -28,7 +35,7 @@ to reduce the amount of network interaction necessary.
 @cindex version backups
 
 @cindex automatic version backups
-  When VC sees that the CVS repository for a file is on a remote
+  When VC sees that the 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
@@ -47,7 +54,7 @@ as ordinary Emacs backup files
 @end ifnottex
 But they follow a similar naming convention.
 
-  For a file that comes from a remote CVS repository, VC makes a
+  For a file that comes from a remote 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
@@ -58,10 +65,10 @@ setting @code{vc-cvs-stay-local} to @code{nil} (@pxref{CVS Options}).
 of file @var{file} is @code{@var{file}.~@var{version}.~}.  This is
 almost the same as the name used by @kbd{C-x v ~}
 @iftex
-(@pxref{Old Versions,,,emacs, the Emacs Manual}),
+(@pxref{Old Revisions,,,emacs, the Emacs Manual}),
 @end iftex
 @ifnottex
-(@pxref{Old Versions}),
+(@pxref{Old Revisions}),
 @end ifnottex
 the only difference being the additional dot (@samp{.})  after the
 version number.  This similarity is intentional, because both kinds of
@@ -244,10 +251,10 @@ you need not hesitate to create snapshots whenever they are useful.
   You can give a snapshot name as an argument to @kbd{C-x v =} or
 @kbd{C-x v ~}
 @iftex
-(@pxref{Old Versions,,,emacs, the Emacs Manual}).
+(@pxref{Old Revisions,,,emacs, the Emacs Manual}).
 @end iftex
 @ifnottex
-(@pxref{Old Versions}).
+(@pxref{Old Revisions}).
 @end ifnottex
 Thus, you can use it to compare a snapshot against the current files,
 or two snapshots against each other, or a snapshot against a named
diff --git a/doc/misc/ChangeLog b/doc/misc/ChangeLog
index 056ad379127..364b2796ac0 100644
--- a/doc/misc/ChangeLog
+++ b/doc/misc/ChangeLog
@@ -1,3 +1,9 @@
+2007-10-10  Michael Albinus  <michael.albinus@gmx.de>
+
+        Sync with Tramp 2.1.11.
+
+        * trampver.texi: Update release number.
+
 2007-10-06  Michael Albinus  <michael.albinus@gmx.de>
 
         * tramp.texi (External packages): New section.
diff --git a/doc/misc/cc-mode.texi b/doc/misc/cc-mode.texi
index eb69733b61c..f4d65ed07aa 100644
--- a/doc/misc/cc-mode.texi
+++ b/doc/misc/cc-mode.texi
@@ -208,8 +208,8 @@ license to the document, as described in section 6 of the license.
 @vskip 0pt plus 1filll
 @insertcopying
 
-This manual was generated from $Revision: 1.2 $ of $RCSfile: cc-mode.texi,v $, which can be
-downloaded from
+This manual was generated from cc-mode.texi, which can be downloaded
+from
 @url{http://cvs.savannah.gnu.org/viewcvs/emacs/emacs/doc/misc/cc-mode.texi}.
 @end titlepage
 
diff --git a/doc/misc/trampver.texi b/doc/misc/trampver.texi
index 4ed196a80f0..179af979c06 100644
--- a/doc/misc/trampver.texi
+++ b/doc/misc/trampver.texi
@@ -4,12 +4,12 @@
 @c In the Tramp CVS, the version number is auto-frobbed from
 @c configure.ac, so you should edit that file and run
 @c "autoconf && ./configure" to change the version number.
-@set trampver 2.1.11-pre
+@set trampver 2.1.11
 
 @c Other flags from configuration
 @set instprefix /usr/local
 @set lispdir /usr/local/share/emacs/site-lisp
-@set infodir /usr/local/info
+@set infodir /usr/local/share/info
 
 @c Formatting of the tramp program name consistent.
 @set tramp @sc{tramp}