Thanks, Larry and Branden. I'll try to work what you're saying into my paper.

Larry, I found your post of a few days ago (https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html) very illuminating, and I'd like to reference it, which I could do with that post. But, is there some other, more referenceable article saying the same thing that I can reference instead?

Regarding BK vs. Git. Even if BK is superior, can today's developers use BK? My understanding is that it is no longer supported.

Is there a DVCS out there that's an alternative to Git?

The reason why this part of my paper has to be short is that I'm discussing the influence of SCCS on software engineering, and its influence on DVCSs is very indirect. My paper isn't a history of VCSs.

Marc

On Sat, Dec 14, 2024 at 11:53 AM Larry McVoy <lm@mcvoy.com> wrote:

On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
> At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
> > As I mentioned in another post, I'm writing an invited paper for an
> > upcoming issue of IEEE Transactions on Software Engineering that will
> > be a 50-year retrospective of my original 1975 SCCS paper (
> > mrochkind.com/aup/talks/SCCS-Slideshow.pdf). Can some people here
> > review a couple of paragraphs for accuracy?
>
> I apologize for this not being quite responsive to your query, then.
>
> 1. Tom Lord's Arch (ca. 2001) was at one timely recognized for
> popularizing, or perhaps _introducing_, the notion of decentralized
> version control to the dot-com era of hard-scrabble FLOSS developers
> who were building "Web 2.0" and whose startup employers, be they
> flush with cash or not, generally would not spring for a commercial
> VCS (which might not have been decentralized anyway).

BitKeeper was 3 years into development by then. Here is the first BK
changeset:

ChangeSet@1.1, 1999-03-19 16:11:26-08:00, lm@lm.bitmover.com
BitKeeper gets stored in BitKeeper.

> The most salient point here is that Linus Torvalds was not prescient
> or uniquely perceptive in recognizing the value of a DVCS.

Couldn't agree more. He, Dave Miller, and Richard Henderson came to my
house in SF because Dave was threatening to fork Linux because Linus
used no SCM at all. That pushed all the merges to the next level, to
people like Dave. It took me 4-5 hours of explaining how distributed
SCM would work for Linus to get it. My wife was unimpressed with him.
Whatever, at the end of that day, he said "build that and I'll use it".
And we did, he did, and rate of development doubled (according to the
people who hated me) and was actually about 10x faster (according to the
people who could do math).

> 2. "TeamWare and BitKeeper took advantage of the interleaved delta
> algorithm, also known as a weave, to implement an efficient way to
> represent merged deltas by reference, instead of reproducing code
> inside the repository. This is a lot more complicated to do with
> reverse deltas, introduced by RCS.*"
>
> I'd a like a second footnote directing me to where I can understand
> the mathematics supporting this claim. Just out of nerd interest.

See if this helps:

https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html

You can work out that SCCS/BK are doing what they claim by running
bk annotate on a file that was authored by X but automerged by Y.
The authorship stays the same across the merge, that's not true in
most SCM systems that copy the data from the branch to the trunk.

Happy to answer any questions. And, yes, git is a ginormous step
backwards. Only one graph, BK had a graph per file so the GCA is
always the correct one, none of this try different ones until you
get one that automerges; since there is only one graph, all you
get are commit comments, you lose the oh-so-valuable-file-comments
that you need when the crap hits the fan; you lose a boat load of
performance, especially in areas like annotate/blame when the repo
gets big, etc. Git sucks, it really does. Linus claims he wrote
it in a week and it shows.
--
---
Larry McVoy Retired to fishing http://www.mcvoy.com/lm/boat