5 ms·
We used SCCS on a satellite constellation demonstration system. Two developers shared archives via an NFS mounted shared file system. SCCS was a “check out” mod
by russfink 3y ago
We used SCCS on a satellite constellation demonstration system. Two developers shared archives via an NFS mounted shared file system. SCCS was a “check out” model, in that if you wanted to make a change, you first acquired a lock, made your edits, then checked it in releasing the lock.
Collections of revisions were self managed as you say.
RCS came along and I think that’s where the $Id$ construct came in. This would expand to the version number of that particular file - if you const char * const idstr = “$Id$” then you could “strings” your binary and see what components were there. Of course, fileguard #ifdef’s would affect this.
Finally, CVS (maybe) had the idea of tagging, which would associate a single label across a current snapshot of different files and their versions.
In 1993-94, ClearCase came on the scene and tried monetizing this concept. A site license cost $30k in 1994 dollars and required a kernel patch for it to work. Try explaining that to your DEC, HP or Sun representative. The software implemented its own filesystem - you would set some kind of version label on a directory and then magically all files and sub folders would appear as of that date. This included libraries, binaries, data files, even crash dumps.
This is all from memory, someone can fact check and correct the finer details.
Nice blog post!
- Scubabear68 3y agoClearcase. Ugh. Only had to use it on one job in the 2000’s, man was it terrible to use. Very slow, required weird file system drivers and access. Horrific GUI. Semantic model was simply broken. Systems like Clearcase is where “release manager” type roles were born. One poor guy would become the expert trying to bang a release out of it over weeks or months.
- eichin 3y agoClearCase was basically a spinoff of Apollo's DSEE (same engineers), which didn't need kernel patches, because Domain/OS actually had an object filesystem and so the reference-to-repo was just a filesystem object. (As with ClearCase, it wasn't so much the software cost as the 1-3 FTEs you needed to be sacrificial experts to tune and manage it.) (insert "mimic a fraction of our power" meme here, though that applies to a lot of Apollo stuff :-) RCS had tags but they were single file tags; the two big things CVS gave you were "this collection of RCS files means something as a whole" (which made tags and branches meaningful) and "you can sort-of-efficiently update from a repo on the other side of the country". (The former was the entire point: CVS was written so Solbourne could maintain their multi-cpu-SunOS fork and still pull changes from upstream; the latter was from Cygnus having a similar upstream+local problem and developers distributed across the planet.)