[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