+@node Remote Repositories
+@subsection Remote Repositories
+@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.
+
+ 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.
+
+ 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.
+* Local Version Control:: Using another version system for local editing.
+@end menu
+
+@node Version Backups
+@subsubsection Version Backups
+@cindex version backups
+
+@cindex automatic version backups
+ 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
+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
+@iftex
+(@pxref{Backup,,,emacs, the Emacs Manual}).
+@end iftex
+@ifnottex
+(@pxref{Backup}).
+@end ifnottex
+But they follow a similar naming convention.
+
+ 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
+setting @code{vc-cvs-stay-local} to @code{nil} (@pxref{CVS Options}).
+
+@cindex manual version backups
+ 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 ~}
+@iftex
+(@pxref{Old Revisions,,,emacs, the Emacs Manual}),
+@end iftex
+@ifnottex
+(@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
+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
+@cindex local version control
+@cindex local back end (version control)
+
+When you make many changes to a file that comes from a remote
+repository, it can be convenient to have version control on your local
+machine as well. You can then record intermediate versions, revert to
+a previous state, etc., before you actually commit your changes to the
+remote server.
+
+VC lets you do this by putting a file under a second, local version
+control system, so that the file is effectively registered in two
+systems at the same time. For the description here, we will assume
+that the remote system is CVS, and you use RCS locally, although the
+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 @code{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 checks 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
+backup (@pxref{Version Backups}). If the unmodified version is not
+available locally, the RCS master starts with the modified version;
+the only drawback to 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
+version, starting a branch from it. For example, if the current CVS
+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
+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
+disabled for RCS, so that editing under RCS works exactly as under
+CVS.
+
+When you are done with local editing, you can commit the final version
+back to the CVS repository by typing @kbd{C-u C-x v v cvs @key{RET}}.
+This initializes the log entry buffer
+@iftex
+(@pxref{Log Buffer,,,emacs, the Emacs Manual})
+@end iftex
+@ifnottex
+(@pxref{Log Buffer})
+@end ifnottex
+to contain all the log entries you have recorded in the RCS master;
+you can edit them as you wish, 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 using local RCS, you can pick up recent changes from the CVS
+repository into your local file, or commit some of your changes back
+to CVS, without terminating local RCS version control. To do this,
+switch to the CVS back end temporarily, with the @kbd{C-x v b} command:
+
+@table @kbd
+@item C-x v b
+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} ``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 are using local RCS, and you want to pick up some recent
+changes in the file from remote CVS, first visit the file, then type
+@kbd{C-x v b} to switch to CVS, and finally use @kbd{C-x v m
+@key{RET}} to merge the news
+@iftex
+(@pxref{Merging,,,emacs, the Emacs Manual}).
+@end iftex
+@ifnottex
+(@pxref{Merging}).
+@end ifnottex
+You can then switch back to RCS by typing @kbd{C-x v b} again, and
+continue to edit locally.
+
+But if you do this, the revision numbers in the RCS master no longer
+correspond to those of CVS. Technically, this is not a problem, but
+it can become difficult to keep track of what is in the CVS repository
+and what is not. So we suggest that you return from time to time to
+CVS-only operation, by committing your local changes back to the
+repository using @kbd{C-u C-x v v cvs @key{RET}}.
+
+@node Revision Tags
+@subsection Revision Tags
+@cindex tags and version control
+
+ In a VCS with per-file revision numbers (such as SCCS, RCS, or CVS)
+@dfn{tag} is a named set of file versions (one for each registered
+file) that you can treat as a unit. In a VCS with per-repository
+version numbers (Subversion and most later ones) a tag is simply
+a symbolic name for a revision.
+
+ One important kind of tag is a @dfn{release}, a (theoretically)
+stable version of the system that is ready for distribution to users.
+
+@menu
+* Making Revision Tags:: The tag facilities.
+* Revision Tag Caveats:: Things to be careful of when using tags.
+@end menu
+
+@node Making Revision Tags
+@subsubsection Making and Using Revision Tags
+
+ There are two basic commands for tags; one makes a
+tag with a given name, the other retrieves a named tag.
+
+@table @code
+@kindex C-x v s
+@findex vc-create-tag
+@item C-x v s @var{name} @key{RET}
+Define the working revision of every registered file in or under the
+current directory as a tag named @var{name}
+(@code{vc-create-tag}).
+
+@kindex C-x v r
+@findex vc-retrieve-tag
+@item C-x v r @var{name} @key{RET}
+For all registered files at or below the current directory level,
+retrieve the tagged revision @var{name}. This command will
+switch to a branch if @var{name} is a branch name and your VCS
+distinguishes branches from tags.
+(@code{vc-retrieve-tag}).
+
+This command reports an error if any files are locked at or below the
+current directory, without changing anything; this is to avoid
+overwriting work in progress.
+@end table
+
+Tags are inexpensive, so you need not hesitate to create them whenever
+they are useful. Branches vary in cost depending on your VCS; in
+older ones they may be expensive.
+
+ You can give a tag or branch name as an argument to @kbd{C-x v =} or
+@kbd{C-x v ~}
+@iftex
+(@pxref{Old Revisions,,,emacs, the Emacs Manual}).
+@end iftex
+@ifnottex
+(@pxref{Old Revisions}).
+@end ifnottex
+Thus, you can use it to compare a tagged version against the current files,
+or two tagged versions against each other.
+
+@node Revision Tag Caveats
+@subsubsection Revision Tag Caveats
+
+ For SCCS, VC implements tags itself; these tags are visible only
+through VC. Most later systems (including CVS, Subversion, bzr, git,
+and hg) have a native tag facility, and VC uses it where
+available; those tags will be visible even when you bypass VC.
+
+ There is no support for VC tags using GNU Arch yet.
+
+ Under older VCSes (SCCS, RCS, CVS, early versions of Subversion),
+renaming and deletion could create some difficulties with tags. This is
+not a VC-specific problem, but a general design issue in version
+control systems that was not solved effectively until the earliest
+third-generation systems.
+
+ In a file-oriented VCS, when you rename a registered file you need
+to rename its master along with it; the command @code{vc-rename-file}
+will do this automatically. If you are using SCCS, you must also
+update the records of the tag, to mention the file by its new name
+(@code{vc-rename-file} does this, too). An old tag that refers to a
+master file that no longer exists under the recorded name is invalid;
+VC can no longer retrieve it. It would be beyond the scope of this
+manual to explain enough about RCS and SCCS to explain how to update
+the tags by hand.
+
+ Using @code{vc-rename-file} makes the tag remain valid for
+retrieval, but it does not solve all problems. For example, some of the
+files in your program probably refer to others by name. At the very
+least, the makefile probably mentions the file that you renamed. If you
+retrieve an old tag, the renamed file is retrieved under its new
+name, which is not the name that the makefile expects. So the program
+won't really work as retrieved.
+
+@node Miscellaneous VC
+@subsection Miscellaneous Commands and Features of VC
+
+ This section explains the less-frequently-used features of VC.
+
+@menu
+* Change Logs and VC:: Generating a change log file from log entries.
+* Renaming and VC:: A command to rename both the source and master
+ file correctly.
+* Version Headers:: Inserting version control headers into working files.
+@end menu
+
+@node Change Logs and VC
+@subsubsection Change Logs and VC
+
+ If you use RCS or CVS for a program and also maintain a change log
+file for it
+@iftex
+(@pxref{Change Log,,,emacs, the Emacs Manual}),
+@end iftex
+@ifnottex
+(@pxref{Change Log}),
+@end ifnottex
+you can generate change log entries automatically from the version
+control log entries:
+
+@table @kbd
+@item C-x v a
+@kindex C-x v a
+@findex vc-update-change-log
+Visit the current directory's change log file and, for registered files
+in that directory, create new entries for versions checked in since the
+most recent entry in the change log file.
+(@code{vc-update-change-log}).
+
+This command works with RCS or CVS only, not with any of the other
+back ends.
+
+@item C-u C-x v a
+As above, but only find entries for the current buffer's file.
+
+@item M-1 C-x v a
+As above, but find entries for all the currently visited files that are
+maintained with version control. This works only with RCS, and it puts
+all entries in the log for the default directory, which may not be
+appropriate.
+@end table
+
+ For example, suppose the first line of @file{ChangeLog} is dated
+1999-04-10, and that the only check-in since then was by Nathaniel
+Bowditch to @file{rcs2log} on 1999-05-22 with log text @samp{Ignore log
+messages that start with `#'.}. Then @kbd{C-x v a} visits
+@file{ChangeLog} and inserts text like this:
+
+@iftex
+@medbreak
+@end iftex