[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: DOCPATCH: History of version control systems

From: <kbrannen_at_gte.net>
Date: 2002-11-07 18:13:47 CET

Ketil Z. Malde wrote:
> Zack Brown <zbrown@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
Received on Thu Nov 7 18:11:44 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.