[TUHS] SCCS

[Larry McVoy]

On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote:
> Larry McVoy wrote in <20190914015517.GD12480 at mcvoy.com>:
>  |On Sat, Sep 14, 2019 at 01:03:12AM +0200, Steffen Nurpmeso wrote:
>  |> He is as convinced from SCCS and its interleaved deltas as you
>  |> are, but he works on extending the plain original SCCS, which is
>  |> pretty smaller; his presentation from the "Chemnitzer Linux Tage
>  |> 2012" (linux days of former Karl-Marx-Stadt) [1] talks about this
>  |> and also prominently mentions BitKeeper:
>  |> 
>  |>   . All modern distributed OSS version control systems base upon
>  |>     BitKeeper in the end.
>  |
>  |Sort of.  Monotone, Darcs, and one other one I can't remember did not
>  |draw from BitKeeper.  Mercurial, Git, and the Australian one that I
>  |can't remember definitely do.
>  |
>  |>   . BitKeeper bases upon the ideas of TeamWare.
>  |
>  |Only in that I am the primary author of both.  It does support the idea
>  |that SCCS is the basis for both, though Teamware used the real SCCS and
>  |I rewrote SCCS from scratch and then extended it quite a bit.  BitKeeper's
>  |SCCS tracks a lot more than SCCS does, pathnames, permissions, hostnames,
>  |etc.
> 
> Regarding the technical background J??rg mentions US Patent 5481722
> on merging deltas of source code control for computer software
> development that Glenn Skinner of Sun holds.

Yeah, it's nuts that Glenn got that patent.  It's true it was his idea
to do the graph that way, and he had an implementation that created
the graph through multiple calls to stripdel, get, and delta.  It was
excruciatingly slow.

100% of the code that implemented the one pass "zipper"-ing of 2 
diverged SCCS files was designed and written by me.  At the very
least, I should have been coauthor of the patent but Sun politics
got in the way [1].  

>  |>   . TeamWare bases upon the ideas of NSE.
>  |
>  |That's absolutely false.  TeamWare, which is the productized version
>  |of NSElite, which I wrote all of, was a reaction to how absolute shiite
>  |NSE was.  I had friends in the Sun kernel group that quit because they
>  |were forced to use NSE.  It was awful.  I got into source management 
>  |because I was well known at Sun as the guy that could fix performance
>  |problems so I was asked to look at NSE.  One look told me that I couldn't
>  |fix NSE but the source management problem space needed some help.

[1] The politics had to do with Teamware.  I wrote all the code in
NSElite, including smoosh(1) which was what the patent covered (though
the patent happened later).  Everyone in the kernel group were using
NSElite because NSE sucked so hard.  But it wasn't sanctioned code,
it was a Larry project.  Bill Shannon would walk around and tell people
that they couldn't use NSElite but they ignored him because it worked
and it was light years faster than NSE.

They couldn't kill NSElite so they decided to toss it to an 8 person
team in the tools group.  They told me if I wanted to work on tools I
had to go join the tools group.  Yeah, right, I'm in the kernel group
and I'm going to take the 3 step downgrade to tools?  I don't think so.

I just kept on supporting and developing NSElite, which was 90% perl4
and a xview graphical program to view history and smoosh (both C).
Because I was coding most of the stuff in (very stylized perl, I rewrote
it 3 times until I had code I could have a hope of maintaining), I was
much faster at rolling out new stuff.  In fact, the 8 people choose to
rewrite everything in C++ which meant I was coding circles around them.
Hence the politics, one guy, in his spare time, while doing a full time
job hacking the kernel, was making 8 guys look like idiots.  Evan later
wrote a paper about what a bad choice C++ was.

Something had to give and Jon Kannegaard, who was the VP of the tools
group, walked into my office and said "I've got Scott's (McNealy, CEO)
approval on this.  If you make one more release of NSElite you are 
fired."  Nice, eh?  Not everything was perfect at Sun.

So I stopped, I left the kernel group and went over and did SPARC Clusters
for Ken Okin.  Glenn filed the patent after I left.

It was a shame because NSElite didn't have changesets, it wasn't really
a distributed system (relied on NFS to get at remote repos), if I had
kept going it would have evolved into what BitKeeper bacame.

Oh, yeah, the politics were so bad that when Evan took smoosh.c he
didn't take any of the SCCS history, he checked it in so it looked like
he wrote it.  Even Shannon called that dirty pool.

>  |>   . NSE is a frontend to SCCS.
>  |
>  |That's true.
>  |
>  |>   . Therewith all modern systems ultimately base upon SCCS.
>  |
>  |That is a big stretch, it's just not true.  I love the SCCS file 
>  |format but to say all modern systems are based on SCCS is 100%
>  |false.  BitKeeper is.  That's it.
>  |
>  |>   . Distributed operate TeamWare, BitKeeper, git, Mercurial.
>  |
>  |Git and Mercurial were going for append only data structures. 
>  |That's not SCCS.
>  |
>  |All this comes from Jorg, isn't he the guy who has a track record of
>  |being on the outside of Sun and trying to argue with me about what Sun
>  |was doing when I was a well known guy in the most important group at Sun,
>  |the kernel group.  If so, I'd salt his stuff heavily.
> 
> This is the J??rg Schilling with whom you have had a dispute on
> this list, yes.  But i do not share this track record of yours.

OK, I'm happy you like him, I liked him just fine until he started 
making statements that aren't true.  Statements that were about 
what Sun was doing and why they were doing it.  Statements about
the content and direction of the kernel development, that I knew
to be false because I was in the Sun kernel group during the time
he was referencing.  Kinda hard to be any closer to it than I was
so unless I've gone completely senile in my old age, I'm probably
more likely to be right about that information than he is.  I was
there, he was not.

> One thing he says, and which is an interesting part of this
> thread, is
> 
>   Die Behauptung von Eric Allman Tichy h??tte SCCS Version
>   1 verwendet kann ich nicht glauben, denn die Ver??ffentlichungen
>   von Tichy sind von 1982 und SCCS war seit Februar 1977 auf der
>   Version 4. SCCS Version 3 hatte ??brigens noch ein bin??res
>   Historyformat.
> 
>   The statement of Eric Allman that Tichy used SCCS version
>   1 i cannot believe, because Tichy's releases are from 1982, and
>   SCCS version 4 was released as earyl as February 1977.  SCCS
>   version 3 used a binary history format, by the way.

Before my time so I don't know.  I was an undergrad Art History major
at that time :)

--lm