This amazing paper holds a special place in my heart: my marked up 1992 copy serving me well when working as a graph and weave engineer on BitKeeper.

To me, SCCS is both a marvel and a disappointment. A marvel because its graph and weave were so far ahead of its time. A disappointment is because for the most part, time didn't build on the innovations, with TeamWare and BitKeeper among the exceptions.

Take the graph: storing history not just as a version graph, but also as a collection of deltas. The 3rd paragraph from end of section II:

"The second kind of special delta is one which, when applied, explicitly forces others deltas to be applied or not, by either including or excluding them. A list of deltas to be included or excluded is specified when such a delta is created. The exclusion facility is most often used simply to correct mistakes. For example if, after delta 3.14 is added, it is found to be undesirable, the programmer might add delta 3.15 which excludes it. If the module is accessed at level 3.14, delta 3.14 itself would be applied. If the module is accessed at a level 3.15, though, delta 3.14 would not be applied. From the viewpoint of control, this form of error correction is safer than allowing the programmer to actually delete a delta, since no potentially necessary information is lost."

Such advanced thinking from 1975! As for the for the brilliance of the weave, ... [1 - adding to mmastrac's reference of J. Schilling's wonderful SCCS pages]

[1]. http://sccs.sourceforge.net/sccs_invention.html

After seeing luckydude answer questions on the little thread the other evening, I'm wondering what other things the SCCS/BK folk think we should be doing better. What have we forgotten?

luckydude mentioned real per-file history for example¹, and that pushed me to remember per-file comments as the thing I'd want back.

Perhaps someone is listening.

¹ https://news.ycombinator.com/item?id=26207037

Branch operations should be first-class transactions in a revision control system. In Git, if you rename branch "foo" to "bar" there's even less record-keeping in place than changes to files. Instead, there should be a first class transaction in the repo history that represents this change.

A reasonable direction to go, and I'll give sort of a non-response. For me, it's to take some time to absorb and celebrate this paper. If I go too quickly to doing better, I tend to miss the amazing. It also makes it easier for me to talk about other's contributions (like luckydude's many) to the state of the art, as then get into what could be better.

An example:

The 4th paragraph from the end of section II talks about optional deltas. It's like ifdefs in a version control system: many version can be checkout with or without some of the deltas. While not part of many version control systems, it's an interesting idea explored in Andreas Zeller's Feature Logic PhD work 20 years later [1].

[1 - currently, SSL cert expired this morning; notified] https://www.st.cs.uni-saarland.de/publications/files/zeller-...

Zeller's design seems to be addressed at least in part by darcs/pijul using the methods described in David Roundy's Theory of Patches¹. A virtual filesystem seems like an especially nice way to solve the interface issues that would arise too.

It strikes me that I treat the result of git-rerere as a ridiculously weak version of this. I'll occasionally carry an unwanted integration branch simply to handle changes that could be managed correctly if there was a better way to express relationships in my tools. Having the functionality baked in to the graph with the associated strictness, and available across clone boundaries would be great.

¹ https://www.cs.tufts.edu/~nr/cs257/archive/david-roundy/Theo...

> It strikes me that I treat the result of git-rerere as a ridiculously weak version of this

I'm the main author of Pijul, and rerere has been my main argument in every discussion about Pijul to explain how everybody is trying to simulate commutation instead of really achieving it.

This is the first time I hear it from somebody else. THANKS!

Also, Darcs' theory doesn't really work around conflicts. Also, until recently, applying a patch in Darcs could take a time exponential in the size of history. It seems to be quadratic in the last few versions (Pijul is in log of the size of history).

If you're familiar with the Zeller paper... Was I right in believing that the approach you're using in pijul allows the use of optional deltas as Zeller's paper describes? I was planning on digging around a little more next weekend, but if you happen to know.

It definitely appears to be a natural extension of the channels feature, but it isn't clear to me that you can express the actual relationship Zeller describes.

I'm not familiar with that thesis. Pijul uses deltas everywhere (but a special form of deltas, storing more information than the output of `diff`), plus tricks to make that fast.

If you're wondering why you might choose SCCS over RCS for your next project, well: http://sccs.sourceforge.net/sccs_vs_rcs.html

If I ever wanted to use something like RCS, I would first take a serious look at SRC: http://www.catb.org/~esr/src/

src is a cute wrapper for rcs, but it has all of the same limitations of rcs, plus a few extra, so I hope you'd consider sccs/cssc if you wanted something "like rcs" but not.

fossil is also a really interesting choice for an "easy setup" version control system, and it's definitely worth considering if you're looking at sccs/cssc: I've used it to log configuration changes for an application, the "push" functionality to centralise changes from tenants, and then I can store issues/tickets (and other metadata) on the configuration changes centrally.

It's pretty hard to take anything Eric S Raymond says seriously, and pretty revolting to look at so many of the things he has said, and he's certainly not easy to work with, so why would you recommend his software?

As you surely know, Eric S Raymond has a long well documented track record of wildly inaccurate claims and outright racism and misogyny, and he regularly inflates and exaggerates his technical competency and achievements.

Thomas Ptacek actually raised $100,000 to stop himself from tweeting vile ESR quotes: he actually raised money to cancel HIMSELF! I bet that's a lot more than ESR has raised on his SRC fundraising page that you linked to and endorsed.

https://twitter.com/tqbf/status/966859542792458240

Some choice quotes (you can pay me to stop, too!):

https://twitter.com/tqbf/status/816449724127608833

ESR> Unfortunately, this doesn't cover the BLM crowd, which would have an average IQ of about 85 if it's statistically representative of Americans blacks as a whole. I've never tried to train anyone that dim and wouldn't want to.

https://twitter.com/tqbf/status/657333910846742528

https://www.dropbox.com/s/55ut8psqeb20tnj/Screenshot%202015-...

> I asked some friends, who tend to be quite nerdy but are mostly not programmers. The only response so far is Ada Lovelace.

ESR> Figures. She doesn't deserve that reputation; "the first programmer" is pure hype created by political animals desperate to conjure up female role models.

https://news.ycombinator.com/item?id=13147038

ESR> I’m wondering about this because my wife Cathy asked me a simple question last night, and I realized I didn’t have an answer to it. “Are you” she asked “the most famous programmer in the world?” This was a question which I had, believe it or not, never thought about before. But it’s a reasonable one to ask, given recent evidence – notably, the unexpected success of my Patreon page. This is relevant because Patreon is mainly an arts-funding site – it’s clearly not designed for or by techies.

Man, that is almost a textbook example of an ad hominem attack.

I try to recommend some useful software, and you go on an unrelated rant about its author, in an obvious attempt to have him cancelled and all his works expunged.

I’m sure all your claims can be either explained as inconsequential or disproven as false, but this is not the time and place for it. Take your ESR-bashing somewhere else.

Reminding the rest of us who ESR actually is strikes me as helpful, the link is to one of his projects.

In terms of "cancelling" him, isn't that up to individuals who decide they do not want to use his software?

> So did you already know about him when you recommended his software, or were those quotes news to you?

I’m not discussing ESR here. I’m discussing you, and your transparent attempt to trap me and try and have me cancelled as well.

People online really need to stop attacking developers personally when discussing their software.

> You are too discussing ESR here.

No, I am not.

> You're the one who brought him up in the first place,

No, I never mentioned him until you did.

> and linked to his fund raising page.

No, I did not. I only linked to one page, the page of the SRC project, which is what I wanted to suggest that people might want to evaluate as an alternative to RCS.

> How did I "trap" you into suddenly trying to change the subject? Who did I ask to "cancel" you? That's "physically impossible", as you would say. ;)

[…]

> Is asking you that a "trap" that will "cancel" you if you answer?

Yes. As is obvious to any but the most casual observer.

> > America, conservatives will tell you, is under siege by “cancel culture.” What they won’t tell you is that they couldn’t be happier about it, since it gives them a handy comeback to any criticism, and helps feed their supporters’ sense of victimization.

Which one of us is trying to cancel anyone right now? Me or you? It’s quite obviously you who’s first trying to cancel ESR for some things unrelated to the software which I suggested, and you are then also trying to get me to argue about ESR, which would make me an easy target for suggesting that I would then somehow be on ESR’s side, responsible for ESR’s opinions and thereby making me eligble for cancellation as well.

EDIT:

> You're on record as having submitted two of his other ridiculously arrogant articles to Hacker News […] you're obviously a fan of his. […] Were you seriously suggesting that ESR would be a good person to collaborate with on developing a source code control system, despite all the evidence? Please explain why. Do you still endorse contributing to his fundraising campaign that you linked to?

Apparently having submitted articles by ESR three years ago is enough to get me smeared as supporting whatever ESR is being accused of. I’m feeling seriously stalked here.

(You neglect to mention that I have also submitted to HN your story about Sun Microsystems PizzaTool. Does this mean that I also endorse your opinions?)

His software does not hold his views and isn't linked to his past conduct. I don't see why it shouldn't be used despite those.

Careful now, the monster you are so busy helping create will come back to rip your head off when you least expect it.

People are complex and opinions change all the time, appreciating the code someone writes has very little to do with anything else.

I'm not afraid of Eric S Raymond ripping my head off, and I certainly didn't create him. He did make a death threat to Bruce Perens, but never followed through with it, and has been mercilessly mocked and ridiculed about it ever since.

https://lists.debian.org/debian-user/1999/04/msg00623.html

The irony of Eric S Raymond threatening someone else for behaving "like that kind of disruptive asshole in public" is rich -- very rich.

Bruce Perens Dead:

https://geekz.co.uk/lovesraymond/cat/bruce-perens/page/10

https://geekz.co.uk/lovesraymond/cat/bruce-perens/page/7

https://geekz.co.uk/lovesraymond/archive/terrorismistic

I've known ESR for at least 35 years, and he hasn't changed from being a smarmy jerk, he's just gotten much worse, especially after 9/11, when his racism and islamophobia and violent death threats really started erupting. But he's always been deeply sexist, for as long as I've known him.

https://en.wikiquote.org/wiki/Eric_S._Raymond

>"And for any agents or proxy of the regime interested in asking me questions face to face, I’ve got some bullets slathered in pork fat to make you feel extra special welcome." -Eric S Raymond

>"A clash of civilizations driven by the failure of Islamic/Arab culture (though I would stress the problem of the Islamic commandment to jihad more than he does). I think he [Steven den Beste] is also right to say that our long-term objective must be to break, crush and eventually destroy this culture, because we can't live on the same planet with people who both carry those memes and have access to weapons of mass destruction. They will hate us and seek to destroy us not for what we've done but for what we are." -Eric S Raymond

>"In the U.S., blacks are 12% of the population but commit 50% of violent crimes; can anyone honestly think this is unconnected to the fact that they average 15 points of IQ lower than the general population? That stupid people are more violent is a fact independent of skin color." -Eric S Raymond

>"When I hear the words "social responsibility", I want to reach for my gun." -Eric S Raymond

And in all that time he's never written any impressive code, nor performed any noteworthy hacks, he just talks and talks and talks. He has made his entire career out of trying to tear down RMS and the Free Software Foundation, not doing anything constructive.

One good example of the problem with his "technical" works and his lack of actual experience with the things he likes to talk about so much, is that he makes and promotes outrageously incorrect claims like Linus's Law, which ESR confabulated himself, but misleadingly attributed "in honor of" Linus Torvalds, who never said that:

https://en.wikipedia.org/wiki/Linus's_Law

"Given enough eyeballs, all bugs are shallow."

When in fact:

Given ANY number of eye, "all" bugs are NOT shallow.

Some bugs are NEVER "shallow".

And only a FEW eyes are qualified to see some bugs, while MANY eyes are totally unqualified, including his own:

His mouth is certainly not qualified to make sweeping generalizations about "all" bugs, given his lack of experience as a programmer, and his spectacular public failure at auditing code in his pathetic attempt to discredit the now-exonerated scientists whose code predicted global warming (described below).

Neither "enough eyeballs" nor "the right eyeballs" are a GIVEN, even for open source software.

"Not enough eyeballs" (or "ZERO eyeballs" as he loves to claim) are NOT a GIVEN for proprietary software, because you can license much proprietary source code, and some proprietary source code is available for you to read and audit for free, under licenses like Microsoft's "Shared Source" license.

https://en.wikipedia.org/wiki/Shared_source

And qualified eye balls are NOT FREE, and usually very busy being well paid to look at much more interesting things than poorly written buggy code like OpenSSL. I doubt that Eric Raymond has contributed any of the profits from his books or VA Linux stocks to Theo De Raadt or anyone else who actually takes the long time and tedious effort to actually audit code.

To quote Theo De Raadt: “My favorite part of the “many eyes” argument is how few bugs were found by the two eyes of Eric (the originator of the statement). All the many eyes are apparently attached to a lot of hands that type lots of words about many eyes, and never actually audit code.”

The little experience Raymond DOES have auditing code has been a total fiasco and embarrassing failure, since his understanding of the code was incompetent and deeply tainted by his preconceived political ideology and conspiracy theories about global warming, which was his only motivation for auditing the code in the first place. His sole quest was to discredit the scientists who warned about global warming. The code he found and highlighted was actually COMMENTED OUT, and he never addressed the fact that the scientists were vindicated.

http://rationalwiki.org/wiki/Eric_S._Raymond

>During the Climategate fiasco, Raymond's ability to read other peoples' source code (or at least his honesty about it) was called into question when he was caught quote-mining analysis software written by the CRU researchers, presenting a commented-out section of source code used for analyzing counterfactuals as evidence of deliberate data manipulation. When confronted with the fact that scientists as a general rule are scrupulously honest, Raymond claimed it was a case of an "error cascade," a concept that makes sense in computer science and other places where all data goes through a single potential failure point, but in areas where outside data and multiple lines of evidence are used for verification, doesn't entirely make sense. (He was curiously silent when all the researchers involved were exonerated of scientific misconduct.)

With all due respect; you once stepped in to back me up, and usually speak wisely.

But you're not making any sense here.

The ego based mind set you're perpetuating isn't helping create a future that any of us wants to live in.

I am not the enemy here, neither is ESR, or even Trump.

GNU has a compatible program, CSSC.

Following on from some discussions about SCM history on here over the weekend I was poking around in the history of things too.

The original 1986 CVS¹ is quite interesting from a historical prospective. Given that the implementation is just a bunch of scripts on top of RCS you can see how it plumbed together really easily.

There is a note¹ on Grune's site, that explains the relationship between the scripts and the system people would more likely recognise as CVS(assuming you're old enough to recognise it at all).

¹ https://ftp.sunet.se/mirror/archive/ftp.sunet.se/pub/usenet/...

² https://dickgrune.com/Programs/CVS.orig/CVS_BB_and_GNU

Edit: And I guess you might not recognise the archives in the first footnote either. They're shar files which can be extracted using the files as a script or more simply with unshar from sharutils³.

³ http://www.gnu.org/software/sharutils/

One thing only lightly hinted on is how sccs was designed to tightly couple the source files to the output object files. Imagine super fine grain symbol versioning + loads of metadata for large project management tools. There was also stuff related to version constraints, security, and dynamic dispatching. They had a very different definition of "source control". I still see some odd artifacts of it pop up every so often in AIX object files.

If you'd like to see Marc Rochkind's other stuff, go to https://basepath.com/new/books.php

I can particularly recommend Advanced UNIX Programming (2nd Edition) even though it is a little old.

Wow, he was 66 when he authored an O'Reilly book on developing Chrome apps. That's very impressive. I wonder if I could have the same curiosity on future technologies when I reach that age.

The idea that technology is a place for young people is simply a harmful myth as far as I can tell. Almost all of the most skilled developers I've met IRL are over 40.

I think you both said different things.

Skill level does generally increase experience.

Curiosity with the world does generally decrease with age / experience.

“Citation needed”. In my experience of people older than I, the opposite is true.

> .. Wisdom is cultivated by and linked to curiosity [2], but this link has not received a large amount of attention in lifespan development research. Moreover, research on aging populations has often overlooked the role of curiosity in aging [3], despite curiosity demonstrating connections to enhancements in memory, health, wellbeing, and longevity [3,4,5]. Unfortunately, curiosity is also known to decline as individuals get older [3], and many adults cease to ask big and beautiful questions as they age [6]. ...

https://www.researchgate.net/publication/323716917_Curiosity...

Curiosity in old age: A possible key to achieving adaptive aging

It appears I live in a bubble! Thanks for the info.