From 44caeae4ca18ec67730d397ac1488839d2b415a9 Mon Sep 17 00:00:00 2001 From: "Richard M. Stallman" Date: Sat, 21 Jul 2007 04:51:48 +0000 Subject: [PATCH] (Why Version Control?): Improve previous change. --- man/ChangeLog | 8 ++++++++ man/files.texi | 15 +++++---------- 2 files changed, 13 insertions(+), 10 deletions(-) diff --git a/man/ChangeLog b/man/ChangeLog index 827cff5a57f..e59c7396d65 100644 --- a/man/ChangeLog +++ b/man/ChangeLog @@ -1,3 +1,11 @@ +2007-07-21 Richard Stallman + + * files.texi (Why Version Control?): Improve previous change. + +2007-07-18 Eric S. Raymond + + * files.texi (Why Version Control?): New node. + 2007-07-17 Michael Albinus * tramp.texi: Move @setfilename ../info/tramp up, outside the header diff --git a/man/files.texi b/man/files.texi index ef627ba8402..747b0dba806 100644 --- a/man/files.texi +++ b/man/files.texi @@ -1268,7 +1268,7 @@ you want to use. @subsubsection Understanding the problems it addresses Version control systems provide you with three important capabilities: -@dfn{reversibility}. @dfn{concurrency}, and @dfn{history}. +reversibility, concurrency, and history. The most basic capability you get from a version-control system is reversibility, the ability to back up to a saved, known-good state when @@ -1421,14 +1421,13 @@ the number and severity of conflicts that actually occur. fundamentally locking-based rather than merging-based version-control system in the future, merging-based version-systems sometimes have locks retrofitted onto them for reasons having nothing to do with technology. -@footnote{Usually the control-freak instincts of managers} For this +@footnote{Usually the control-freak instincts of managers.} For this reason, and to support older systems still in use, VC mode supports both locking and merging version control and tries to hide the differences between them as much as possible. @cindex files versus changesets. - - On SCCS. RCS, CVS, and other early version-control systems, checkins + On SCCS, RCS, CVS, and other early version-control systems, checkins and other operations are @dfn{file-based}; each file has its own @dfn{master file} with its own comment- and revision history separate from that of all other files in the system. Later systems, beginning @@ -1440,18 +1439,14 @@ one 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 multiple files has to be backed out, it's good to be able to easily -identify and remove all of it. But it took some years for designers to -figure that out, and while file-based systems are passing out of use -there are lots of legacy repositories still to be dealt with at time of -writing in 2007. +identify and remove all of it. @cindex centralized vs. decentralized - Early version-control systems were designed around a @dfn{centralized} model in which each project has only one repository used by all developers. SCCS, RCS, CVS, and Subversion share this kind of model. It has two important problems. One is that a single repository is a -single point of failure--if the repository server is down all work +single point of failure---if the repository server is down all work stops. The other is that you need to be connected live to the server to do checkins and checkouts; if you're offline, you can't work. -- 2.39.5