From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE,SUBJ_ALL_CAPS autolearn=ham autolearn_force=no version=3.4.2 Received: from minnie.tuhs.org (minnie.tuhs.org [45.79.103.53]) by inbox.vuxu.org (OpenSMTPD) with ESMTP id 998f2426 for ; Mon, 16 Sep 2019 20:32:11 +0000 (UTC) Received: by minnie.tuhs.org (Postfix, from userid 112) id 82EAD9BDC7; Tue, 17 Sep 2019 06:32:10 +1000 (AEST) Received: from minnie.tuhs.org (localhost [127.0.0.1]) by minnie.tuhs.org (Postfix) with ESMTP id 9E8CD9478F; Tue, 17 Sep 2019 06:31:55 +1000 (AEST) Received: by minnie.tuhs.org (Postfix, from userid 112) id 81BF49478F; Tue, 17 Sep 2019 06:31:53 +1000 (AEST) Received: from mcvoy.com (mcvoy.com [192.169.23.250]) by minnie.tuhs.org (Postfix) with ESMTPS id 07EBC9478D for ; Tue, 17 Sep 2019 06:31:53 +1000 (AEST) Received: by mcvoy.com (Postfix, from userid 3546) id 83B2B35E11A; Mon, 16 Sep 2019 13:31:52 -0700 (PDT) Date: Mon, 16 Sep 2019 13:31:52 -0700 From: Larry McVoy To: Larry McVoy , emanuel stiebler , Clem Cole , Eric Allman , TUHS main list , J??rg Schilling Message-ID: <20190916203152.GB9704@mcvoy.com> References: <20190912034346.GJ2046@mcvoy.com> <1457a2d6-2f17-482d-e4f7-ace439d34ca8@neophilic.com> <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com> <20190913211104.aMZXy%steffen@sdaoden.eu> <20190913211751.GF2046@mcvoy.com> <20190913230312.XaeCQ%steffen@sdaoden.eu> <20190914015517.GD12480@mcvoy.com> <20190916172300.cjlkf%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190916172300.cjlkf%steffen@sdaoden.eu> User-Agent: Mutt/1.5.24 (2015-08-30) Subject: Re: [TUHS] SCCS X-BeenThere: tuhs@minnie.tuhs.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: The Unix Heritage Society mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tuhs-bounces@minnie.tuhs.org Sender: "TUHS" On Mon, Sep 16, 2019 at 07:23:00PM +0200, Steffen Nurpmeso wrote: > Larry McVoy wrote in <20190914015517.GD12480@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