Mercurial > emacs

--- a/doc/emacs/ChangeLog	Wed Oct 10 15:03:07 2007 +0000
+++ b/doc/emacs/ChangeLog	Wed Oct 10 15:29:31 2007 +0000
@@ -1,7 +1,10 @@
 2007-10-10  Eric S. Raymond  <esr@snark.thyrsus.com>

-	* files.texi (Version Systems): Merge in changes for new VC
-	with fileset-orienrted operations.
+	* files.texi (Version Systems):
+	* vc-xtra.texi:
+	* vc1-xtra.texi:
+	* vc2-xtra.texi: Merge in changes for new VC
+	with fileset-oriented operations.

 2007-10-09  Eric S. Raymond  <esr@snark.thyrsus.com>
--- a/doc/emacs/vc-xtra.texi	Wed Oct 10 15:03:07 2007 +0000
+++ b/doc/emacs/vc-xtra.texi	Wed Oct 10 15:29:31 2007 +0000
@@ -15,7 +15,7 @@
 @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.
--- a/doc/emacs/vc1-xtra.texi	Wed Oct 10 15:03:07 2007 +0000
+++ b/doc/emacs/vc1-xtra.texi	Wed Oct 10 15:29:31 2007 +0000
@@ -120,21 +120,27 @@
   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 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.

-  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.
+  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
--- a/doc/emacs/vc2-xtra.texi	Wed Oct 10 15:03:07 2007 +0000
+++ b/doc/emacs/vc2-xtra.texi	Wed Oct 10 15:29:31 2007 +0000
@@ -6,17 +6,20 @@
 @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 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.
+  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 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.
+  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.

 @menu
 * Version Backups::        Keeping local copies of repository versions.
@@ -28,7 +31,7 @@
 @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 +50,7 @@
 @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