You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Zack Brown <zb...@tumblerings.org> on 2002/11/06 20:07:22 UTC
RFC: DOCPATCH: History of version control systems
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
Re: RFC: DOCPATCH: History of version control systems
Posted by Branko Čibej <br...@xbc.nu>.
Zack Brown wrote:
>+ <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
>
"her house"
>+ moonless night, take them from their cozy bed and proceed to
>+ execution.</para>
>
"him from his bed" -- nice and Equal. :-)
FWIW, modulo the Rational<->Atria "bug", I like this. I hope the Authors
in Their Wisdom will find it convenient to include this bit into the Work.
--
Brane Čibej <br...@xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by Zack Brown <zb...@tumblerings.org>.
Actually, I'd better just let the actual authors take care of generating
text. As Ben pointed out to me, there's a lot more involved than just
adding content. I'm just happy to be able to watch this book take shape
in a public forum, and to point out the occassional spelling mistake.
And there are many other docs to be maintained [rubbing hands together
in anticipation]
Be well,
Zack
On Wed, Nov 06, 2002 at 11:07:11PM +0100, Benjamin Pflugmann wrote:
> On Wed 2002-11-06 at 13:24:08 -0800, Zack Brown wrote:
> [...]
> > I'm happy to take that out if that's what folks want. For the record, my
> > thinking has been that to a good history of version control, the technical
> > details form a central part. I was planning on adding *more* technical
> > details to subsequent revisions, to elucidate how the features and
> > problems unfolded. Bad?
> [...]
>
> I see.
>
> Hm. You want to give people some background to why Subversion is like
> it is, by showing them how CVS evolved, don't you?
>
> How about splitting that up into two parts, a general history section
> (which also could be a little bit less CVS-centric) and a more
> technical section, which could show why version control systems are
> like they are today. Like
>
> "A history of version control" and
> "A technical history Subversion" (including CVS, of course)
>
> You already have those two parts, just not as cleanly sperated. I am
> not good at writing such things, but I am sure, you got the idea.
>
> Regards,
>
> Benjamin.
>
>
--
Zack Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
On Wed 2002-11-06 at 13:24:08 -0800, Zack Brown wrote:
[...]
> I'm happy to take that out if that's what folks want. For the record, my
> thinking has been that to a good history of version control, the technical
> details form a central part. I was planning on adding *more* technical
> details to subsequent revisions, to elucidate how the features and
> problems unfolded. Bad?
[...]
I see.
Hm. You want to give people some background to why Subversion is like
it is, by showing them how CVS evolved, don't you?
How about splitting that up into two parts, a general history section
(which also could be a little bit less CVS-centric) and a more
technical section, which could show why version control systems are
like they are today. Like
"A history of version control" and
"A technical history Subversion" (including CVS, of course)
You already have those two parts, just not as cleanly sperated. I am
not good at writing such things, but I am sure, you got the idea.
Regards,
Benjamin.
Re: RFC: DOCPATCH: History of version control systems
Posted by Zack Brown <zb...@tumblerings.org>.
On Wed, Nov 06, 2002 at 10:07:22PM +0100, Benjamin Pflugmann wrote:
> Hi.
>
> On Wed 2002-11-06 at 12:07:22 -0800, Zack Brown wrote:
> > 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?
>
> First, let me say, I like the direction. I really enjoyed reading it.
Cool!
> > + <para>while not perfect, this new situation at least allowed R to do
> > + meaningful work, without waiting for Q.</para>
>
> For my taste, that is a bit too theoretic for the history part. How
> about giving Q and R real names, at least?
OK.
>
> But, personally, I think that this kind of example is not needed in
> such an overview at all. A deeper understanding of CVS's working is
> not needed at this time, is it?
I'm happy to take that out if that's what folks want. For the record, my
thinking has been that to a good history of version control, the technical
details form a central part. I was planning on adding *more* technical
details to subsequent revisions, to elucidate how the features and
problems unfolded. Bad?
>
> [...]
> > + <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
>
> You never mentioned that CVS repositories wouldn't be on their own
> computer. I think you somewhere went from local to remote repositories
> without explicitly mentioning this.
You caught me. This was going to be part of my
adding-more-technical-details revisions.
Thanks for the comments!
Zack
>
> HTH,
>
> Benjamin.
>
--
Zack Brown
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by Benjamin Pflugmann <be...@pflugmann.de>.
Hi.
On Wed 2002-11-06 at 12:07:22 -0800, Zack Brown wrote:
> 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?
First, let me say, I like the direction. I really enjoyed reading it.
[...]
> + <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>
For my taste, that is a bit too theoretic for the history part. How
about giving Q and R real names, at least?
But, personally, I think that this kind of example is not needed in
such an overview at all. A deeper understanding of CVS's working is
not needed at this time, is it?
[...]
> + <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
You never mentioned that CVS repositories wouldn't be on their own
computer. I think you somewhere went from local to remote repositories
without explicitly mentioning this.
HTH,
Benjamin.
Re: RFC: DOCPATCH: History of version control systems
Posted by kb...@gte.net.
Ketil Z Malde wrote:
> kbrannen@gte.net writes:
>>>[RCS incorporated the]
>>>
>>>>+ branching features of SCCS, and introduced the ability for multiple
>>>>+ developers to work on the same programming project at the same
>>>>+ time.</para>
>>>So I guess SCCS subsequently borrowed this back from RCS, then?
>>
>>Nope. While SCCS used the locking model by default, you could turn
>>that off.
>
> Uh - how is that different from RCS? Doesn't RCS also use locking for
> multiple developers? I thought you needed CVS for concurrent versions
> (and thus the name)?
The difference is in the default. SCCS locks unless you tell it not to, RCS
does not lock unless you tell it to. Other than that, they are conceptually
the same tool. (Yes, I know they have various features that are different,
but I'm talking about the concept of locking while versioning, not who can
annotate/checksum/whatever and who can not.)
(If you'll allow a little CYA...) At least this is how I remember them. It
has been awhile since I've had to use those tools in the raw; but using them
has made me appreciate the "higher level" tools (e.g. CVS, ClearCase, Aegis,
Subversion).
If you have multiple developers doing potentially concurrent work, the 2 basic
models are: lock while you work, or work & merge where necessary. Discussing
which is better my get you into a "religious war"; :-) but I'll tempt fate and
say that my personal opinion is the latter is preferred, but there are times
where locking is useful. No matter which model is used, you can do concurrent
development--I've worked successfully under both models.
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by Ketil Z Malde <ke...@ii.uib.no>.
kbrannen@gte.net writes:
>> [RCS incorporated the]
>>>+ branching features of SCCS, and introduced the ability for multiple
>>>+ developers to work on the same programming project at the same
>>>+ time.</para>
>> So I guess SCCS subsequently borrowed this back from RCS, then?
> Nope. While SCCS used the locking model by default, you could turn
> that off.
Uh - how is that different from RCS? Doesn't RCS also use locking for
multiple developers? I thought you needed CVS for concurrent versions
(and thus the name)?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by kb...@gte.net.
Ketil Z. Malde wrote:
> Zack Brown <zb...@tumblerings.org> writes:
...
>>+ <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.
>
>
> Since I don't know the history, I'll just assume you've got the facts
> right. Is it really true that the point of SCCS was to conserve
> space? Surely that is the least of the benefits -- and I guess that
> must have quickly become evident.
You must remember that back then, disk space and memory were both very
expensive. OTOH, I would say that saving disk space was the #2 or #3 reason
(at least for my group). The most important reason for us using SCCS was to
recover gracefully when someone tried to put something in production that had
errors in it, and SCCS allowed us to quickly revert back to older working code.
>
> Perhaps this (or a link) could be posted to some of the old farts'
> newsgroups, for feedback? (Not sure which ng is most appropriate,
> though)
Thanks! :-) That's the first time I've ever been called that. :-)
>
> [RCS incorporated the]
>
>>+ branching features of SCCS, and introduced the ability for multiple
>>+ developers to work on the same programming project at the same
>>+ time.</para>
>
>
> So I guess SCCS subsequently borrowed this back from RCS, then?
Nope. While SCCS used the locking model by default, you could turn that off.
But that also meant you (the next person to check-in) were responsible for
merging your code in (by hand IIRC); hence, it was better to allow SCCS to
lock the file to avoid that issue. I still have semi-fond memories of SCCS,
as well as a C/Motif front end for SCCS that I wrote (it was like tkcvs).
>
>
>>+ <para>Gradually, CVS became the standard tool used in software
>>+ projects everywhere.
>
>
> Surely this is an overstatement?
I think he means from an OSS point of view, in which case he's quite correct.
Though your comment points out that assumption needs to be stated. :-)
...
> Rational bought ClearCase (from PureAtria?), didn't they? Anyway,
> that's not important.
Yes, the product was owned by Atria -> PureAtria -> Rational. I believe I
have a coffee mug from the first 2 companies around here somewhere. :-) The
Clearcase/Multisite combo are awesome, and IMO the standard to measure all
other systems by (if you're in a larger company). And yes, I used to be a
CC/MS admin. :-)
...
>>+ by BitKeeper. Another attempt has been the Aegis project by Peter
>>+ Miller, also a direct attempt to replace CVS.</para>
>
>
> I thought Aegis was more of a process control thing than a version
> control thing -- and that it plugs in version control (and can use
> e.g. CVS). It's been a while since I looked at it, am I wrong?
Not by much. Aegis promotes itself as a "CASE tool", though I would say it's
purpose is version control and development control together (i.e. you can't
have one without the other). In it's most "strict" configuration, it would be
a good tool to help you go up the SEI scale. You can tell Aegis which version
tool to use (from the list of: fhist, RCS, SCCS only), but it makes
assumptions about said tool that I'm not sure CVS can do (CVS is too high
level and would get in Aegis's way). I like Aegis a lot, and have used it
until recently; but I hate it's distribed (remote) work model/abilities. This
is what's driving me to look at subversion. I've always liked CVS's
master/slave remote work model, and svn is fixing many of CVS's faults.
From an old something... ;-)
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: RFC: DOCPATCH: History of version control systems
Posted by "Ketil Z. Malde" <ke...@ii.uib.no>.
Zack Brown <zb...@tumblerings.org> writes:
> + <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>
I think (I'm too young to remember) it was common to fix errors by
punching new holes and/or applying patches to erroneously punched
holes? (Indeed, this may be the etymology for "patch" -- anybody
know?) Perhaps this deserves a mention?
> + <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.
Since I don't know the history, I'll just assume you've got the facts
right. Is it really true that the point of SCCS was to conserve
space? Surely that is the least of the benefits -- and I guess that
must have quickly become evident.
Perhaps this (or a link) could be posted to some of the old farts'
newsgroups, for feedback? (Not sure which ng is most appropriate,
though)
[RCS incorporated the]
> + branching features of SCCS, and introduced the ability for multiple
> + developers to work on the same programming project at the same
> + time.</para>
So I guess SCCS subsequently borrowed this back from RCS, then?
> + <para>Gradually, CVS became the standard tool used in software
> + projects everywhere.
Surely this is an overstatement?
> + To this day it is by far the most popular version
> + control system in use in the world.
Are you *sure*? Lots of people use Sorta^H^H^HurceSafe, being the
"default" choice for Windows developers. Lots of people still use RCS
or SCCS for personal work.
I'd add a "probably" in there. Or restrict it to public/distributed
development.
> + Over time, however, users did
> + begin to recognize some deficiencies in CVS,
Also, it is better to consider a patch as a set of changes to several
files (the SVN way), rather than a set of changes to one file (CVS).
I.e. have per repository history, rather than per file history.
While the things you mention are inconveniences, this point represents
something more fundamental in how you view source control -- a change
of paradigm, if you will.
> + <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
Rational bought ClearCase (from PureAtria?), didn't they? Anyway,
that's not important.
> + 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.
...and a fundamentally different model of development. Perhaps
mention that it was tailored to fit the Linux kernel MoD?
> + by BitKeeper. Another attempt has been the Aegis project by Peter
> + Miller, also a direct attempt to replace CVS.</para>
I thought Aegis was more of a process control thing than a version
control thing -- and that it plugs in version control (and can use
e.g. CVS). It's been a while since I looked at it, am I wrong?
> + attempts, Subversion is one of the more interesting ones. It is not a
> + true filesystem like ReiserFS,
But can't it be, with Linux and davfs? (I've really no idea, but it
seems one should be able to mount a subversion repository like any
other file system, doesn't it?)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org