From b3eb2cf8c304847e0e7abb3081b0dcca64559eb5 Mon Sep 17 00:00:00 2001 From: "Eric S. Raymond" Date: Tue, 11 Nov 2014 21:55:01 -0500 Subject: [PATCH] Minor language polishing. --- FAQ.asc | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/FAQ.asc b/FAQ.asc index 838daa9..49d640f 100644 --- 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 -- 2.43.0