Zack Brown <zbrown@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
Received on Thu Nov 7 11:04:12 2002