Hi folks,
I thought it would be best to post something like this here for discussion
instead of just committing it. It fills in the section in Chapter 1 of the
book, dealing with the history of version control. It's not necessarily
finished, but I wonder if I'm going in the right direction.
Comments?
(this passes xmllint, but I admit I haven't compiled it yet)
Be well,
Zack
Index: doc/book/book/ch01.xml
===================================================================
--- doc/book/book/ch01.xml (revision 3668)
+++ doc/book/book/ch01.xml (working copy)
@@ -34,7 +34,7 @@
sections that describe Subversion's concurrent versioning model.
Also, there is a quick guide for CVS users attached as an appendix
<xref linkend="svn-ap-a"/></para>
-
+
</sect1>
<!-- ================================================================= -->
@@ -46,46 +46,201 @@
<sect2 id="svn-ch-1-sect-3.1">
- <title>History of Revision Control</title>
-
- <para>Subversion is a free/open-source <firstterm>version
- control system</firstterm>. That is, Subversion manages
- files over time. The files are placed into a central
- <firstterm>repository</firstterm>. The repository is much
- like an ordinary file server, except that it remembers every
- change ever made to your files. This allows you to recover
- older versions of your files, or browse the history of how
- your files changed. Many people think of a version control
- system as a sort of ``time machine.''</para>
-
- <para>Some version control systems are also <firstterm>software
- configuration management</firstterm> (SCM) systems. These
- systems are specifically tailored to manage trees of source
- code, and have many features that are specific to software
- development (such as natively understanding programming
- languages). Subversion, however, is not one of these
- systems; it is a general system that can be used to manage
- <emphasis>any</emphasis> sort of collection of files,
- including source code.</para>
-
+ <title>History of Version Control</title>
+
+ <para>In the beginning, there was the punch-card. Computer programmers
+ would specify programming commands via the series of punched holes in
+ the card. They would give the card to the computer operator, who would
+ run it when its turn came. The programmer would receive the output, go
+ home, and create a new card that fixed bugs and added functionality.
+ Version control consisted of the stack of old cards growing in the
+ corner next to the hamburger wrappers and empty soda bottles.</para>
+
+ <para>By 1975 however, the situation had changed. Instead of
+ punch-cards, programs began to be stored on magnetic disk media, and
+ it became convenient, or at least more convenient, to keep older
+ versions of programs around, just in case something went wrong with
+ the latest and greatest. But with new solutions come new problems.
+ Each byte of disk space had to be paid for, and keeping any number of
+ nearly identical copies of a given program could get expensive. At
+ this time, Marc Rochkind of AT&T got the idea of keeping only one
+ main copy of any given file, along with a set up updates containing
+ only the differences between the original and newer versions. He
+ called his tool a Source Code Control System, or SCCS for
+ short.</para>
+
+ <para>SCCS saved huge amounts of disk space (and moolah), and added an
+ element of organization to one's work. It became possible to refer
+ meaningfully to earlier versions of a program, using version numbers.
+ It was also possible, even somewhat convenient, to branch a tree of
+ development, and make diverging changes to those branches. If it was
+ discovered that development had begun to move in the wrong direction,
+ the developer could roll back to an earlier state, and continue
+ development from there.</para>
+
+ <para>SCCS was a wonderful advance over the old way of doing things,
+ but it was itself difficult and unwieldy. For small projects, or
+ projects in which only one or two branches of development might have
+ to coexist, it was quite useful; but for larger projects involving
+ many branches and multiple developers, SCCS was very reluctant.</para>
+
+ <para>Nevertheless, it remained the only choice for about ten years,
+ until Walter Tichy from Purdue University brought out his Revision
+ Control System (RCS) in 1985. RCS retained the version numbering and
+ branching features of SCCS, and introduced the ability for multiple
+ developers to work on the same programming project at the same
+ time.</para>
+
+ <para>Allowing many people to insert their contributions into the
+ versioning system posed an interesting problem. What if two people
+ made changes to the same file at almost the same time? Wouldn't one
+ person's changes overwrite the other's? Tichy's RCS system dealt with
+ this in a clear but heavy-handed way: when one person checked out a
+ file to make changes, the file became locked, and no one else could
+ change it until the first person checked it in again.</para>
+
+ <para>While this ensured that no developer's changes would be
+ inadvertently lost, it was not particularly friendly to all the
+ developers waiting to edit a given file. It also invented the
+ situation in which one developer checks out a file and forgets about
+ it, until the other developers surround their house with torches on a
+ moonless night, take them from their cozy bed and proceed to
+ execution.</para>
+
+ <para>Barely a year after the arrival of RCS, a new system arrived in
+ 1986 from Dick Grune, Brian Berliner, and Jeff Polk, called the
+ Concurrent Versioning System (CVS). CVS also allowed multiple
+ developers to work on the same project, but instead of implementing
+ file locking, CVS would simply refuse to accept file modifications
+ that conflicted with target files in the main
+ <firstterm>repository</firstterm>. These conflicts were instead
+ reported back to the developer offering the submission, who would be
+ expected to resolve the conflicts by hand and resubmit.</para>
+
+ <para>To illustrate this situation, consider the situation in which
+ developer Q and developer R edit the same location of the same file. Q
+ checks the new file back into the repository without any problem,
+ because the changes map cleanly onto the file already existing in the
+ repository. However, when R attempts to submit changes to the same
+ file, suddenly the situation has changed. The file in the repository
+ is significantly different from the file R began to edit, and so R's
+ changes no longer map cleanly onto that file. CVS cannot fulfill R's
+ request, and instead informs R that there are conflicts between R's
+ version of the file, and the version in its repository. R then
+ compares the two files, identifies the incompatibilities, and
+ resubmits his work, taking account of Q's changes as well.</para>
+
+ <para>while not perfect, this new situation at least allowed R to do
+ meaningful work, without waiting for Q.</para>
+
+ <para>Gradually, CVS became the standard tool used in software
+ projects everywhere. To this day it is by far the most popular version
+ control system in use in the world. Over time, however, users did
+ begin to recognize some deficiencies in CVS, and to yearn for an
+ alternative. One of these was its inability to correctly handle
+ renaming files. If a developer wished to change a file's name, the
+ file first had to be deleted from the repository, and a new file
+ created with the desired name. While this did accomplish the desired
+ result, CVS kept no record of the fact that the two files were in fact
+ the same. Even if their contents were identical, the only way to
+ discover that after the fact was to examine the contents by eye. Thus,
+ developers attempting to roll back to an earlier version of a project
+ could get confused, and be forced to waste time hunting around for the
+ truth.</para>
+
+ <para>Another problem with CVS was that a directory, once created,
+ could not be removed or renamed. There were hacks to get around this,
+ such as having the root user delete the directory from the repository
+ on the server, but in that case, the whole history of that directory
+ would be lost, effectively destroying the value of all project
+ versions up to that point.</para>
+
+ <para>Everyone recognized that these problems existed, but it was
+ difficult to see how to fix them. Because of the way CVS had been
+ written, many of its problems were intrinsic, and fixing them would
+ require a complete redesign and rewrite of the code. Since CVS had
+ grown and matured, adding many useful features, and since it was at
+ least adequate for most projects, it took a long time for anyone to
+ become so fed up with it, that they were willing to put in the time
+ and effort needed to create a replacement that not only solved CVS'
+ intrinsic problems, but also measured up to CVS' impressive existing
+ feature set.</para>
+
+ <para>Among their technical similarities, CVS, RCS, and SCCS all
+ shared the fact that they were free programs. Anyone could download,
+ use, and even modify them at the source level. Eventually, companies
+ like Rational and BitMover began to realize that professional software
+ houses, as well as companies the didn't specialize in software
+ development but still relied on it, would pay good money for a product
+ that would solve the remaining problems of CVS. As no free replacement
+ seemed to be forthcoming, a genuine market seemed to have identified
+ itself.</para>
+
+ <para>These commercial <firstterm>version control systems</firstterm>
+ did more than just solve the problems of CVS. They radically changed
+ the way version control was handled. In the case of BitMover's
+ BitKeeper product, the entire idea of a central repository was
+ discarded in favor of a client-based system, in which each developer
+ kept a full repository on their own computer. This allowed a
+ tremendous increase in the size of project that could be supported.
+ Developers could splinter off into groups, work together on code that
+ retained full versionability, and then feed their changes back to the
+ key maintainers of various areas and sub-areas of the project. Code
+ could be exchanged between developers and groups of developers, either
+ by 'pushing' changes from their tree into another, or by 'pulling'
+ changes from elsewhere into their own.</para>
+
+ <para>These new commercial version control systems were, however,
+ quite expensive, well beyond the reach of most developers working on
+ free software in their spare time. The need for a free CVS replacement
+ was still felt by many developers throughout the world. Various
+ projects sprang up from time to time to try to meet this need, but
+ none have achieved the success of CVS. One attempt to extend CVS into
+ the realm of BitKeeper-like ability was DCVS, an extension of CVS to
+ allow distributed repositories that would be similar to those produced
+ by BitKeeper. Another attempt has been the Aegis project by Peter
+ Miller, also a direct attempt to replace CVS.</para>
+
+ <para>Other attempts at re-envisioning a version control system have
+ involved moving the relevant data into the filesystem. ReiserFS is one
+ example of a filesystem that hopes one day to keep records of every
+ change made to every file and directory, as part of the filesystem
+ itself.</para>
+
+ <para>Still other attempts have expanded the vision of version control
+ into <firstterm>software configuration management</firstterm> (SCM).
+ These systems are specifically tailored to manage trees of source
+ code, and have many features that are specific to software development
+ (such as natively understanding programming languages).</para>
+
+ <para>Many, many attempts have been made or are being made, to solve
+ the dual problems of matching CVS' existing features in a free
+ product, while simultaneously eradicating the problems and
+ shortcomings that persist in CVS. Among these more or less interesting
+ attempts, Subversion is one of the more interesting ones. It is not a
+ true filesystem like ReiserFS, nor a SCM, nor a proprietary system
+ like BitKeeper. Instead, it is a straightforward attempt to address
+ the perrennial problems of CVS, without attempting to redefine the
+ meaning of version control.</para>
+
</sect2>
-
+
<sect2 id="svn-ch-1-sect-3.2">
-
+
<title>History of Subversion</title>
-
+
<para>Subversion aims to be the successor to the
<firstterm>Concurrent Versions System</firstterm> (CVS). You
can find more information about CVS at <systemitem
class="url">http://www.cvshome.org/</systemitem>.</para>
-
+
<para>At the time of writing, CVS is the standard Free version
control system used by the open-source community. It has a
hard-earned, well-deserved reputation as stable and useful
software, and has a design that makes it perfect for
open-source development. However, it also has a number of
problems that are difficult to fix.</para>
-
+
<para>Subversion's original designers settled on a few simple
goals. First, it was decided that Subversion should be a
functional replacement for CVS. That is, it should do
@@ -94,7 +249,7 @@
existing CVS users as the first target audience, Subversion
should be written such that any CVS user should be able to
start using it with little effort.</para>
-
+
<para>Collabnet <systemitem
class="url">http://www.collab.net/</systemitem> provided the
initial funding in 2000 to begin development work, and the
@@ -146,7 +301,7 @@
versioned over time, just like file contents.</para>
</listitem>
</varlistentry>
-
+
<varlistentry>
<term>Hackability</term>
<listitem>
@@ -207,7 +362,7 @@
</chapter>
<!--
-local variables:
+local variables:
eval: (load-file "../tools/svnbook.el")
sgml-parent-document: ("book.xml" "chapter")
end:
--
Zack Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 6 21:08:08 2002