[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

On Dec 14, 2024, at 3:54 PM, Luther Johnson &lt;luther.johnson(a)makerlisp.com&gt; wrote: "Is there a DVCS out there that's an alternative to Git?" I'm sure the list will offer many options, but I think you might want to look into mentioning either Fossil or Mercurial as alternatives to Git. I have used Mercurial a tiny bit, and I have used Fossil regularly over the last several years. Considering commercial (not open source) software, I think Perforce is another candidate, I have used it before, not lately, but at the time I used it, I think it had a reasonably large customer base. On 12/14/2024 12:13 PM, Marc Rochkind wrote: > 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 &lt;lm(a)mcvoy.com <mailto: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 <http://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 <mailto:ChangeSet@1.1>, 1999-03-19 16:11:26-08:00, lm(a)lm.bitmover.com <mailto: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 > > > > -- > My new email address is mrochkind(a)gmail.com <mailto:mrochkind@gmail.com>