[TUHS] SCCS, TeamWare, BitKeeper, and Git
Luther Johnson
luther.johnson at makerlisp.com
Sun Dec 15 06:54:27 AEST 2024
"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 <lm at mcvoy.com
> <mailto:lm at 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 at 1.1, 1999-03-19 16:11:26-08:00, lm at lm.bitmover.com
> <mailto:lm at 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 at gmail.com <mailto:mrochkind at gmail.com>/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20241214/01f06e24/attachment-0001.htm>
More information about the TUHS
mailing list