[Emacs-diffs] Changes to emacs/doc/emacs/files.texi,v

[Eric S. Raymond]

CVSROOT:        /sources/emacs
Module name:    emacs
Changes by:     Eric S. Raymond <esr>   07/10/11 14:13:19

Index: files.texi
===================================================================
RCS file: /sources/emacs/emacs/doc/emacs/files.texi,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -b -r1.8 -r1.9
--- files.texi  10 Oct 2007 23:22:48 -0000      1.8
+++ files.texi  11 Oct 2007 14:13:19 -0000      1.9
@@ -1213,11 +1213,10 @@
   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}
@@ -1428,7 +1427,7 @@
 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.
 
@@ -1444,11 +1443,11 @@
 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 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.
+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
@@ -1462,12 +1461,12 @@
 @cindex files versus changesets.
   On SCCS, RCS, CVS, and other early version-control systems, checkins
 and other operations are @dfn{file-based}; each file has its own
address@hidden file} with its own comment- and revision history separate
address@hidden 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
@@ -1479,7 +1478,7 @@
 
   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
+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
@@ -1620,15 +1619,15 @@
 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 throw an error when you attempt to execute 
+If they are not, VC mode will fail when you attempt to execute 
 a command on the fileset.
 
-   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.
+   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
address@hidden commit} with those file arguments at the shell command
+line in the directory of the selected buffer.
 
    If you are used 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