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 (
) 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(a)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(a)1.1, 1999-03-19 16:11:26-08:00, lm(a)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
--
*My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*