Minor language polishing.

diff --git a/FAQ.asc b/FAQ.asc
index 838daa94dd4c11cac2d016f57e4a7622c032f273..49d640fbce7762d69f3c5235f5be7a34274c89a2 100644 (file)
--- a/FAQ.asc
+++ b/FAQ.asc
@@ -1,10 +1,11 @@
 = SRC FAQ =
+version 1.0
 
 == Why SRC instead of $VCS? ==
 
-Most version control systems today are ostensibly multi-user,
+Most version control systems today are multi-user,
 multi-file, and multi-fork oriented. These are all good features and
-properties to have, but it neglects the need to maintain simple
+properties to have, but they neglect the need to maintain simple
 single-file documents, such as HOWTOs and FAQs, much like the very
 file you are reading now. There is even a good use-case for small
 programs and scripts. Do you presently keep your ~/bin contents under
@@ -12,15 +13,15 @@ version control? If not, consider using SRC for them.
 
 == XYZ already does single-file version control, why another one? ==
 
-It is true, other VCSes already fulfill this simple criteria, SCCS and
-RCS being some of the earliest examples dating back to the 1970s and
+It is true, other VCSes already fulfill this simple criterion, SCCS
+and RCS being some of the earliest examples dating back to the 1970s and
 1980s. While SCCS died off due to its proprietary nature, RCS has kept
-a nice for itself precisely for single-file projects. In fact, SRC is
+a niche for itself precisely for single-file projects. In fact, SRC is
 built on top of RCS, rather than reimplementing all of the gritty
 master file details.
 
-The idea that had spawned the development of SRC was that it would
-have four properties characterizing it:
+The idea that spawned the development of SRC was that it would
+have five properties characterizing it:
 
 * Only deals with single files. Use for HOWTOs, memoranda, etc.
 
@@ -36,8 +37,9 @@ Notably, RCS itself fails on the latter two criteria. Designed both as
 an early attempt at VCS and for multi-user environments, the commands
 are awkward to deal with and it even requires complicated processes of
 locking and unlocking files in order to edit and commit them. None of
-this is appropriate anymore. Modern DVCSes by large are used for
-multi-user projects and wide coordination.
+this is appropriate anymore. Modern DVCSes with a non-locking model
+have proven more effective for multi-user projects and wide
+coordination.
 
 Other projects to mold Mercurial and Git for a single-file purpose at
 the very least will fail criteria #3 and #5, and often #4 as well.
@@ -48,7 +50,7 @@ Absolutely not! SRC and DVCSes serve entirely opposite needs. SRC’s
 strength is precisely when there is no need nor desire for
 collaboration or publishing features, when there is only a single file
 and a single author for a file. In fact, if your script grows into a
-full project of its own right, SRC has a src fast-export command that
+full project in its own right, SRC has a 'src fast-export command' that
 can be used to jump-start a DVCS repository with the entire existing
 history intact.
 
@@ -131,10 +133,10 @@ No, though the author admits he did laugh a lot while roughing out the
 original design. Resurrect RCS?  Wrap it in a decent UI?  Really?
 
 There's a significant amount of ha-ha-only-serious here.  Laugh, but
-treat SRC as a serious lesson in several things.  Unix minimalism. 
-The virtue of re-use, even of technology as old as RCS.  The value
-of a carefully designed UI.  The value of a conservative design with
-no surprises and no undue cleverness.
+treat SRC as a lesson in several things.  Unix minimalism.  The virtue
+of re-use, even of technology as old as RCS.  The value of a carefully
+designed UI.  The value of a conservative design with no surprises and
+no undue cleverness.
 
 What *will* be funny is when we implement the back end to talk to
 SCCS.  It won't be difficult, that whole end of the interface is