Re: [TUHS] SCCS

Re: [TUHS] SCCS

[Norman Wilson]

Well, if we're going to get into editor, erm, version-control wars,
I'll state my unpopular opinion that SCCS and RCS were no good at
all and CVS only pretended to be any good.  Subversion was the first
system I could stand using.

The actual basis for that opinion (and it's just my opinion but it's
not pulled out of hyperspace) is that the older systems think only
about one file at a time, not collections of files.  To me that's
useless for any but the most-trivial programming (and wasn't
non-trivial programming what spurred such systems?).  When I am
working on a non-trivial program, there's almost always more than
one source file, and to keep things clean often means refactoring:
splitting one file into several, merging different files, removing
files that contain no-longer-useful junk, adding files that
implement new things, renaming files.

A revision-control system that thinks only about one file at a
time can't keep track of those changes.  To me that makes it
worse than useless; not only can it not record a single
commit with a single message and version number when files
are split and combined, it requires extra work to keep all
those files under version control at all.

CVS makes an attempt to handle those things, but the effect
is clunky in practice compared to successors like svn.

One shouldn't underestimate the importance of a non-clunky
interface.  In retrospect it seems stupid that we didn't have
some sort of revision control discipline in Research UNIX, but
given the clunkiness of SCCS and RCS and CVS, there's no way
most of us would have put up with it.  Given that we often had
different people playing with the same program concurrently,
it would have taken at least CVS to meet our needs anyway.

Norman `recidivist' Wilson
Toronto ON

Re: [TUHS] SCCS

[Larry McVoy]

On Fri, Sep 13, 2019 at 05:37:12PM -0400, Norman Wilson wrote:
> The actual basis for that opinion (and it's just my opinion but it's
> not pulled out of hyperspace) is that the older systems think only
> about one file at a time, not collections of files.  

Yep.  That's the problem that BitKeeper solved first, correctly, with
atomic commits, full rename tracking, etc.  If you googled "changeset"
back in 1996 before BitKeeper started happening there were 6 hits
(mostly for a really weird system called Aide De Camp).

If you googled it 5 years later there were millions of hits, almost
100% BitKeeper related.

One of the selling points of BK back in the day was "remember when you
forgot to tag the tree in CVS and you couldn't get back to where you
wanted to be?  Yeah, every commit in BK is a tag, you can roll back
to anywhere."

So I agree with you Norm that exact problem was part of why BitKeeper
was invented.  When I was going on about SCCS, I was admiring the weave,
it's a neat way to do things.  But I wouldn't suggest anyone use just
SCCS today, that's nuts.

Re: [TUHS] SCCS

[Steffen Nurpmeso]

Eric Allman wrote in <94341a28-723a-f177-f658-0c827b35591b@neophilic.com>:
 |On 2019-09-16 19:23 , Steffen Nurpmeso wrote:
 |> One thing he says, and which is an interesting part of this
 |> thread, is
 |> 
 |>   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.
 |> 
 |> That should have addressed Eric Allman, but the longer i use email
 |> in the public space the more i like that pub-like feeling.  (And
 |> not going to add that it reminds me of my childhood, where i was
 |> a boy under elder seasoned men _also_.)
 |
 |I did not claim that Tichy used SCCS v1.  It's worse than that.  He only
 |read the IEEE paper, which pre-dated RCS --- so far as I know he never
 |even tried SCCS release 4 (current at the time Tichy published), which
 |fixed the obvious problem in the release 1 design as originally
 |published.  Despite careful descriptions of the changes, he refused to
 |stop slandering SCCS.  He was truly standing on toes, not shoulders.

Thank you.  I will forward your response to Jörg.

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[Eric Allman]

On 2019-09-16 19:23 , Steffen Nurpmeso wrote:
> One thing he says, and which is an interesting part of this
> thread, is
> 
>   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.
> 
> That should have addressed Eric Allman, but the longer i use email
> in the public space the more i like that pub-like feeling.  (And
> not going to add that it reminds me of my childhood, where i was
> a boy under elder seasoned men _also_.)

I did not claim that Tichy used SCCS v1.  It's worse than that.  He only
read the IEEE paper, which pre-dated RCS --- so far as I know he never
even tried SCCS release 4 (current at the time Tichy published), which
fixed the obvious problem in the release 1 design as originally
published.  Despite careful descriptions of the changes, he refused to
stop slandering SCCS.  He was truly standing on toes, not shoulders.

eric

Re: [TUHS] SCCS

[Steffen Nurpmeso]

Larry McVoy wrote in <20190916203152.GB9704@mcvoy.com>:
 |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.

Thank you for this look into the Sun internals, the above sounds
manlike, and that in High-Tech!

 |>|>   . 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.

Hm, he started running into this list for sure.  Since you guys
are there for several decades, who can tell in between the line
fluxes, me not.  All i know is that if you interview multiple
people on the same topic, then you will hear multiple stories,
practically always.  Transporting history by hearsay is what made
us great, wa.  I will never forget documentation of some natives
in the Indonesian djungle, the kings envoy only said that he is
exactly that, was scanned by many eyes, .. and accepted.
So even if Jörg has a hearsay account on the Sun internals in
question, i cannot blame him for standing upon that ground.

 |> 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
 --End of <20190916203152.GB9704@mcvoy.com>

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[Larry McVoy]

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

Re: [TUHS] SCCS

[Steffen Nurpmeso]

Hello.

Please excuse the late reply, your message (and many more) landed
in the spam folder, i have adjusted the subject again.

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.

 |>   . 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.
 |
 |>   . 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.
To me he is a person who distributed parts of my free software
infrastructure when that was much smaller than today, and enabled
me to burn CDs, which was a thing in the ninetees.  And to the
best of my knowledge he was an actor behind the berliOS open
source hub, which lost its financial support alongside other
German software projects (afaik) in the second half of the 2000's,
and therefore rebased its users to Sourceforge.  And more.

I do not know about Sun let alone its internals, but i know for
sure he worked with Sun code already in the 80s, and it seems he
worked for a company who was working with Sun code very tightly.
Since he is from Berlin where all the friendly communicative
people come from it seems not unlikely that he got good hooks here
and there, so why 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.

That should have addressed Eric Allman, but the longer i use email
in the public space the more i like that pub-like feeling.  (And
not going to add that it reminds me of my childhood, where i was
a boy under elder seasoned men _also_.)

 |I think he means well but is a little out there.  Though some people
 |might say the same about me.

I also think he means well.  The rest i do not know about,
Larry McVoy.  I am a Buddhist also, and the Austrian Emperor even
wanted to pardon also a woman who i think tortured and killed her
own child, and the death penalty came back only due to massive
pressure from the population.  Jörg in turn says, i cite (and
translate a bit loose), "Larry is good, but regarding himself
a little bit too offensive".  Without meaning any harm i think
this can well be said, and is a key for making it in New York,
without ever having been there.  Bob Dylan even went electric!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[Steffen Nurpmeso]

Bakul Shah wrote in <20190913214905.339ED1570CE9@mail.bitblocks.com>:
 |On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@mcvoy.com> wrote:
 |> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
 |>> 
 |>> I for one am so happy to have git that i cannot tell you how much
 |>> that is.  I have used rcs, cvs, subversion, back to cvs,
 |>> mercurial over the years,, and for some small things also sccs.
 |>> All of it has been a pain here or there.  Yes, the weave.  Schily
 |>> wants to provide real changeset support for sccs (tagging is real
 |>> problem), i think.  
 |>
 |> I don't know why, BitKeeper does that and is open source under 
 |> a liberal license (Apache v2).
 |
 |This is because in git the "id" of a changeset is its sha1
 |checksum.  Given that, you can only reference it in a
 |subsequent changeset. This is a problem in that there is no
 |git built-in way to correlate a built binary with a particular
 |changeset id of its sources but you end up using your own
 |convention.  E.g.  set env. var VERSION or some such to the id
 |during the compile step but it is a bother.

Linus Torvalds wrote an interesting message on that many years
ago, which someone pointed me at ditto.  Do not ask.  git cannot
generate human readable things by design, with branching and
merging, and due to the distributed nature.  I have a little (git
pre-commit) script which keeps my SCCS IDs alive for my web pages,
even after i converted them to git.  But i think for code bases
like NetBSD in particular this is a total show stopper (they
really keep the "original" file preamble alive, do they?), but it
also is for OpenBSD i think, and for FreeBSD i know that having
a human readible sequentially increasing version number was a main
reason to go for subversion.  Even though there seems to be
a growing number of people who want to switch to git, yes i think
Warner Losh just said something like "when we will have switched
to git, that will xy", this week?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[Steffen Nurpmeso]

Larry McVoy wrote in <20190913211751.GF2046@mcvoy.com>:
 |On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
 |> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.c\
 |> om>:
 |>|On 2019-09-12 19:29, Clem Cole wrote:
 |>|> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name
 |>|> <mailto:tuhs@eric.allman.name>> wrote:
 |>|> 
 |>|>     ??At thispoint I'm using git because, well, all the cool kids are
 |>|>     doing it, and
 |>|>     since I work at the university I have to go with the flow sometimes\
 |>|>     .
 |>|>     And git has some nice properties.?? On the other hand, I have \
 |>|>     shot myself
 |>|>     in the foot with git more times than the sum of all other screwups \
 |>|>     \
 |>|>     with
 |>|>     all other source management systems combined.
 |>|> 
 |>|>     eric
 |>|> 
 |>|> +1??
 |>|
 |>|I have this one on the waqll in the office:
 |>|https://xkcd.com/1597/
 |> 
 |> I for one am so happy to have git that i cannot tell you how much
 |> that is.  I have used rcs, cvs, subversion, back to cvs,
 ...
 |> All of it has been a pain here or there.  Yes, the weave.  Schily
 |> wants to provide real changeset support for sccs (tagging is real
 |> problem), i think.  
 |
 |I don't know why, BitKeeper does that and is open source under 
 |a liberal license (Apache v2).

Diversity is something good i would say.  With the constraint that
it is real diversity, as nature produces, not as in modern times
where the supermarket has two dozen sorts of margarine, and in the
end it comes from Kraft or Nestle, which bought together
a sortiment, and that is basically it, which (i bore you) has to
result in save effects which dilutes recipes or ingredients.  (I
am the happy eater of Alsan-S, and are paying not getting paid for
it.  But that is ok.)  So in fact this diversity rather is
BitKeeper and Sun SCCS only.  Yet two hears are better than one,
sang Frank Sinatra.

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.
  . BitKeeper bases upon the ideas of TeamWare.
  . TeamWare bases upon the ideas of NSE.
  . NSE is a frontend to SCCS.
  . Therewith all modern systems ultimately base upon SCCS.
  . Distributed operate TeamWare, BitKeeper, git, Mercurial.

This logic convinces me.  First, we take Manhattan, then we take
Berlin.  His SCCS is not a competitor to the BitKeeper suite, of
course.  But it roots in the original Sun code, just as Heirloom
SCCS.

  [1] http://sccs.sourceforge.net/SCCS-Chemnitz-2012.pdf

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[Bakul Shah]

On Fri, 13 Sep 2019 14:17:51 -0700 Larry McVoy <lm@mcvoy.com> wrote:
> On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
> > 
> > I for one am so happy to have git that i cannot tell you how much
> > that is.  I have used rcs, cvs, subversion, back to cvs,
> > mercurial over the years,, and for some small things also sccs.
> > All of it has been a pain here or there.  Yes, the weave.  Schily
> > wants to provide real changeset support for sccs (tagging is real
> > problem), i think.  
>
> I don't know why, BitKeeper does that and is open source under 
> a liberal license (Apache v2).

This is because in git the "id" of a changeset is its sha1
checksum.  Given that, you can only reference it in a
subsequent changeset. This is a problem in that there is no
git built-in way to correlate a built binary with a particular
changeset id of its sources but you end up using your own
convention.  E.g.  set env. var VERSION or some such to the id
during the compile step but it is a bother.

Re: [TUHS] SCCS

[Larry McVoy]

On Fri, Sep 13, 2019 at 11:11:04PM +0200, Steffen Nurpmeso wrote:
> emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>:
>  |On 2019-09-12 19:29, Clem Cole wrote:
>  |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name
>  |> <mailto:tuhs@eric.allman.name>> wrote:
>  |> 
>  |>     ??At thispoint I'm using git because, well, all the cool kids are
>  |>     doing it, and
>  |>     since I work at the university I have to go with the flow sometimes.
>  |>     And git has some nice properties.?? On the other hand, I have \
>  |>     shot myself
>  |>     in the foot with git more times than the sum of all other screwups \
>  |>     with
>  |>     all other source management systems combined.
>  |> 
>  |>     eric
>  |> 
>  |> +1??
>  |
>  |I have this one on the waqll in the office:
>  |https://xkcd.com/1597/
> 
> I for one am so happy to have git that i cannot tell you how much
> that is.  I have used rcs, cvs, subversion, back to cvs,
> mercurial over the years,, and for some small things also sccs.
> All of it has been a pain here or there.  Yes, the weave.  Schily
> wants to provide real changeset support for sccs (tagging is real
> problem), i think.  

I don't know why, BitKeeper does that and is open source under 
a liberal license (Apache v2).

Re: [TUHS] SCCS

[Steffen Nurpmeso]

emanuel stiebler wrote in <8db2e89c-ce50-a453-e38a-ecdfe69a746c@e-bbes.com>:
 |On 2019-09-12 19:29, Clem Cole wrote:
 |> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name
 |> <mailto:tuhs@eric.allman.name>> wrote:
 |> 
 |>      At thispoint I'm using git because, well, all the cool kids are
 |>     doing it, and
 |>     since I work at the university I have to go with the flow sometimes.
 |>     And git has some nice properties.  On the other hand, I have \
 |>     shot myself
 |>     in the foot with git more times than the sum of all other screwups \
 |>     with
 |>     all other source management systems combined.
 |> 
 |>     eric
 |> 
 |> +1 
 |
 |I have this one on the waqll in the office:
 |https://xkcd.com/1597/

I for one am so happy to have git that i cannot tell you how much
that is.  I have used rcs, cvs, subversion, back to cvs,
mercurial over the years,, and for some small things also sccs.
All of it has been a pain here or there.  Yes, the weave.  Schily
wants to provide real changeset support for sccs (tagging is real
problem), i think.  No, stashing, simply commiting something
half-ready, amending, rebasing, and, very important, proper
garbage collection of thrown away or otherwise useless stuff,
i will never miss again.

The only bad aspects is the lack of an automatically expanded,
human readable version number that can be included in files, and
that you cannot simply checkout, say, one directory, but only the
entire repository.  Its capability to work with shallow
repositories has improved over the years, however.  Nonetheless,
i claim that for the maintainer of one or two ports/packages it is
much nicer to use cvs, and only check out what really is of
interest to you; than to checkout thousands of things that is.

A nice weekend from Germany i wish,

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: [TUHS] SCCS

[emanuel stiebler]

On 2019-09-12 19:29, Clem Cole wrote:
> 
> 
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name
> <mailto:tuhs@eric.allman.name>> wrote:
> 
>      At thispoint I'm using git because, well, all the cool kids are
>     doing it, and
>     since I work at the university I have to go with the flow sometimes.
>     And git has some nice properties.  On the other hand, I have shot myself
>     in the foot with git more times than the sum of all other screwups with
>     all other source management systems combined.
> 
>     eric
> 
> +1 

I have this one on the waqll in the office:
https://xkcd.com/1597/

Re: [TUHS] SCCS

[Bakul Shah]

On Fri, 13 Sep 2019 15:22:58 +1000 Dave Horsfall <dave@horsfall.org> wrote:
> On Wed, 11 Sep 2019, Larry McVoy wrote:
>
> > Yeah, this was one of things that BitKeeper addressed.  It was easier to 
> > use and every commit was a tag.
>
> That reminds me: I really must take another look at BK for my stuff.
>
> At the moment I'm using say "fred.c-" for the previous version etc (and 
> "fred.c+" for something finished but not quite ready to install).
>
> I've also renamed entire directory trees to sub-tree under "OLD" etc :-)
>
> SCCS/RCS are history as far as I'm concerned; I never quite got the hang 
> of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories 
> about GIT to keep me away from it...

I used to know CVS quite well.  Then I switched to mercurial
(for my own projects).  Then to git.  git has its problems but
it has worked well enough.  With just a few commands you can
get a lot done with it.  If you rely on/ contribute to any
open source projects, you pretty much have to know it these
days.

Re: [TUHS] SCCS

[Dave Horsfall]

On Wed, 11 Sep 2019, Larry McVoy wrote:

> Yeah, this was one of things that BitKeeper addressed.  It was easier to 
> use and every commit was a tag.

That reminds me: I really must take another look at BK for my stuff.

At the moment I'm using say "fred.c-" for the previous version etc (and 
"fred.c+" for something finished but not quite ready to install).

I've also renamed entire directory trees to sub-tree under "OLD" etc :-)

SCCS/RCS are history as far as I'm concerned; I never quite got the hang 
of CVS (which OpenLDAP uses); and I've heard all sorts of horror stories 
about GIT to keep me away from it...

-- Dave

Re: [TUHS] SCCS

[Nemo]

On 11/09/2019, Larry McVoy <lm@mcvoy.com> wrote:
> On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
>> On Wed, 11 Sep 2019, Larry McVoy wrote:
>>
>> >SCCS is awesome, I'll post why in a different thread.  It is light years
>> >better than RCS, Tichy lied.
>>
>> Agreed; I used it for years, then was forced to use RCS in my next job
>> :-(
>
> Marc Rochkind is on the list, I believe I invited him, but he can spell
> check what I'm about to say.
>
> SCCS is awesome.

I just learnt that Schily maintains source at http://sccs.sourceforge.net/
(Of course, I have it on my Solaris boxen and may now try it on others.)

N.

Re: [TUHS] SCCS

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

On Thu, Sep 12, 2019, 11:30 AM Clem Cole <clemc@ccc.com> wrote:

>
>
> On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name> wrote:
>
>>  At this point I'm using git because, well, all the cool kids are doing
>> it, and
>> since I work at the university I have to go with the flow sometimes.
>> And git has some nice properties.  On the other hand, I have shot myself
>> in the foot with git more times than the sum of all other screwups with
>> all other source management systems combined.
>>
>> eric
>
> +1
>

Mercurial still holds that honor for me. I've screwed up so bad I had to
reclone and lost work. Dozens of times. :(.

Git is just as easy to screw up. And were it not for the extensive "hole in
foot first aid" feature git has, I'd be there too... I hate the cli because
it seems overtly hostile to orthogonality, consistency and logic. But learn
the warts and it gets the job done.

Warner

>

[-- Attachment #2: Type: text/html, Size: 2112 bytes --]

Re: [TUHS] SCCS

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On Thu, Sep 12, 2019 at 1:16 PM Eric Allman <tuhs@eric.allman.name> wrote:

>  At this point I'm using git because, well, all the cool kids are doing
> it, and
> since I work at the university I have to go with the flow sometimes.
> And git has some nice properties.  On the other hand, I have shot myself
> in the foot with git more times than the sum of all other screwups with
> all other source management systems combined.
>
> eric

+1

[-- Attachment #2: Type: text/html, Size: 1029 bytes --]

Re: [TUHS] SCCS

[Eric Allman]

Actually I preferred SCCS for all the reasons that Larry has described.
 But SCCS was encumbered --- usable at the university, but not in a
commercial environment --- so it wasn't available at Britton-Lee at a
price we could afford, and RCS was pretty much the only other game in town.

Tichy was comparing against SCCS version 1, as described in the paper
"The source code control system" (Marc Rochkind, IEEE Transactions on
Software Engineering 1, 4, December 1975), which used forward deltas ---
very slow as your history got big.  I spent considerable time trying to
convince him that the version of SCCS in current production was as Larry
described, where any version could be read in linear time, but he wasn't
hearing anything that went against his beliefs.  So far as I know, he
never even looked at or measured the system he was comparing RCS to.

Today I probably wouldn't use SCCS, mostly because of the atomic update
problem (which was still broken in RCS, but fixed in CVS).  At this
point I'm using git because, well, all the cool kids are doing it, and
since I work at the university I have to go with the flow sometimes.
And git has some nice properties.  On the other hand, I have shot myself
in the foot with git more times than the sum of all other screwups with
all other source management systems combined.

eric


On 2019-09-11 21:28, Jon Forrest wrote:
> 
> 
> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
> what we used at Britton-Lee in the group that Eric Allman was part of.
> SCCS is what we used at Sybase as it was gaining popularity. This was
> so long ago that I don't remember all the details but I found that
> RCS was much easier to use, especially in an environment that didn't
> do much merging. Instead we used labels (or tags, I forget what they
> were called) to mark which files were part of which release. Doing
> this was much harder in SCCS, which contributed to the mess that
> was Sybase software engineering.
> 
> Of course, all this could be explained by Eric's deep knowledge
> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
> But, to me, an early adopter of source code control who wasn't
> overly interested in speed, RCS was much easier to use.
> 
> Jon

Re: [TUHS] SCCS

[Clem Cole]

[-- Attachment #1: Type: text/plain, Size: 4592 bytes --]

Like most things in life, what you value tends to make one thing more
important than another when you consider any object.  This is why programs
like editors; programming languages; and in this case, file revision
management software, gets such visceral responses from so many of us.   And
like many programs and subsystems, as deficiencies become more
obvious/acute with a program, when and how they are addressed also play
into that value.

Thus, I think it comes back to *use case* for everyone.  What am I
protecting with this subsystem and how does it affect me?

Frankly, the high order bit for me, is usually protection from my own
silliness (most important), how easy/natural it is to use/fit into my
workflow(next in importance); followed by accidental/on-purpose changes
happening by my friends/coworkers 'behind my back'(important); how merges
are handled when I'm in a group setting; and IF AND ONLY IF I'm using the
tool kit to protect IP for a 'product', how easy it is to support
'releases' past/current/in-development at the same time.

The truth is, when I'm leading product development, that last one moves up
a few places, although I know that if the 'fit' or ease of using the tool
is not nearly #1, some members of the team will not use said tool in the
planned and expected manner - so I think I will tend to value 'ease of use'
as the most important attribute for me.

Truth is SCCS and from what I know of BitKeeper, has always met my
criteria, certainly for simple programs and even for documents like papers
and books. As I said, its what I use day to day (thank you Marc and team).
While I learned the direct get/admin/delta/prs commands, calling them via
Eric's "sccs(ucb)" front-end 'fixed' the harder to use part of things.
Frankly, I have aliases 'get' to be 'sccs get' and the like.


I was at Tektronix and like many when Tichey released RCS by itself, Eric's
sccs(ucb) command was not available to me, so it seemed simpler and I was
attracted to it.  But I quickly went to UCB and was re-introduced to SCCS
using Eric's front-end and I found the difference was a nit.   SCCS was
what we used, so that became my go-to and has been for a long time.

SCCS was our systems at Masscomp, Stellar and later DEC (although DEC for
OSF/1 switched to another system whose name I forget which came from OSF).
 At LCC, we used what the customer used, so we got to see a lot of them ;-)

That said, when Thinking Machines released CVS-II (on top of RCS) it did
seem like the cvs merge management and production tags tended to be the
easier/a good thing.   When we used that system for an HP project at LCC, I
will say, the Thinking Machine crew had fixed the two issues I had
struggles with SCCS**.   I used cvs again for a few other projects
including two start-ups later.

Since that time, I have been given Mercurial, SVN, and git. I'll ignore the
first two as they seem to have fallen from grace. I personally, find git
extremely heavyweight and only deal with it because I have too thanks so
linux pushing it into so many FOSS projects.  I can and do have to use it,
but my experience is that we fight the tool constantly and I wonder if we
are ahead or behind.  The git system supposed to be great for merges and
so-called 'pull requests' and I can see if what you value is being able to
grab something from someone else - *i.e.* what Linus does daily (merge lots
of peoples 'suggestions') and it probably does make it easier for Linus.
But .... I can say in a product setting, I have observed it is messy to
keep track of specific versions of things that make up a 'product.  For
instance, I would like to be able to query, get me all the sources that
make of the 'Intel Parallel Studio, Cluster Edition'  (I don't think it can
be done!!

At least at DEC, when we released Ultrix, we put a tag into the DB and keep
a DB around for every file we used for the build.  There was a script that
could be run, that get do an 'sccs get' against every file and we could
rebuild everything (VAX or PMAX) and it even included some of the 'layered
products' that the OS team controlled.

So, my observation at Intel, is we have more people wasting backed time on
'maintaining our common pools' here than we ever did at DEC or at any of
start-ups.   As a sr person, I must say hmmmmm

Anyway - that's my 2 cents.


** Although, I'll believe Larry when he says he fixed said SCCS
deficiencies in Bitkeeper.  I will say after a quick examination of doc and
his emails, it does sound like he picked up some of the good ideas from
other systems, but I can not say I have tried it.

[-- Attachment #2: Type: text/html, Size: 7363 bytes --]

Re: [TUHS] SCCS

[William Corcoran]

Okay, while on the subject of SCCS and UNIX:

Is there a UNIX (post SCCS) like System III or System V that still has all of the original SCCS entries intact?  

Would only production ready code be entered as an SCCS delta? 

Or, would SCCS be used as a checkpoint tool to store unofficial versions (even broken versions) of the UNIX codebase as development progressed on the system as a whole?

I would love to see all of the prs for the kernel and commands.  

Truly,

Bill Corcoran

> On Sep 12, 2019, at 12:33 AM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> Yeah, this was one of things that BitKeeper addressed.  It was easier
> to use and every commit was a tag.
> 
>> On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote:
>> 
>> 
>> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
>> what we used at Britton-Lee in the group that Eric Allman was part of.
>> SCCS is what we used at Sybase as it was gaining popularity. This was
>> so long ago that I don't remember all the details but I found that
>> RCS was much easier to use, especially in an environment that didn't
>> do much merging. Instead we used labels (or tags, I forget what they
>> were called) to mark which files were part of which release. Doing
>> this was much harder in SCCS, which contributed to the mess that
>> was Sybase software engineering.
>> 
>> Of course, all this could be explained by Eric's deep knowledge
>> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
>> But, to me, an early adopter of source code control who wasn't
>> overly interested in speed, RCS was much easier to use.
>> 
>> Jon
> 
> -- 
> ---
> Larry McVoy                     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] SCCS

[Larry McVoy]

Yeah, this was one of things that BitKeeper addressed.  It was easier
to use and every commit was a tag.

On Wed, Sep 11, 2019 at 09:28:25PM -0700, Jon Forrest wrote:
> 
> 
> I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
> what we used at Britton-Lee in the group that Eric Allman was part of.
> SCCS is what we used at Sybase as it was gaining popularity. This was
> so long ago that I don't remember all the details but I found that
> RCS was much easier to use, especially in an environment that didn't
> do much merging. Instead we used labels (or tags, I forget what they
> were called) to mark which files were part of which release. Doing
> this was much harder in SCCS, which contributed to the mess that
> was Sybase software engineering.
> 
> Of course, all this could be explained by Eric's deep knowledge
> of RCS, and the lack of somebody with Eric's knowledge at Sybase.
> But, to me, an early adopter of source code control who wasn't
> overly interested in speed, RCS was much easier to use.
> 
> Jon

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

Re: [TUHS] SCCS

[Jon Forrest]

I used both RCS and SCCS in the early days (e.g. 1985 - 1991). RCS was
what we used at Britton-Lee in the group that Eric Allman was part of.
SCCS is what we used at Sybase as it was gaining popularity. This was
so long ago that I don't remember all the details but I found that
RCS was much easier to use, especially in an environment that didn't
do much merging. Instead we used labels (or tags, I forget what they
were called) to mark which files were part of which release. Doing
this was much harder in SCCS, which contributed to the mess that
was Sybase software engineering.

Of course, all this could be explained by Eric's deep knowledge
of RCS, and the lack of somebody with Eric's knowledge at Sybase.
But, to me, an early adopter of source code control who wasn't
overly interested in speed, RCS was much easier to use.

Jon

Re: [TUHS] SCCS

[Jon Steinhart]

George Michaelson writes:
> What Larry and the other RCS haters forget is that back in the day,
> when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.
>
> because running forward edits on a base state of 1000 edits is slow.
> Since the majority action is increment +1 on the head state the RCS
> model, whilst broken in many ways
> was FAST
>
> -G

And also that RCS had a much friendlier interface.

Re: [TUHS] SCCS

[George Michaelson]

If you want to be trendy, call this an event stream, and say its
eventually consistent.

What Larry and the other RCS haters forget is that back in the day,
when we all had more hair, RCS was --->FAST<--- and SCCS was S.L.O.W.

because running forward edits on a base state of 1000 edits is slow.
Since the majority action is increment +1 on the head state the RCS
model, whilst broken in many ways
was FAST

-G

On Thu, Sep 12, 2019 at 10:44 AM Larry McVoy <lm@mcvoy.com> wrote:
>
> On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
> > On Wed, 11 Sep 2019, Larry McVoy wrote:
> >
> > >SCCS is awesome, I'll post why in a different thread.  It is light years
> > >better than RCS, Tichy lied.
> >
> > Agreed; I used it for years, then was forced to use RCS in my next job :-(
>
> Marc Rochkind is on the list, I believe I invited him, but he can spell
> check what I'm about to say.
>
> SCCS is awesome.  People have no idea how good it is as a version control
> system because Walter Tichy got his PhD for writing RCS and claiming it
> was better (don't get me started on how wrong that was).
>
> Let me start with how RCS works.  You all know about diff and patch,
> someone does a diff, produces a patch, and Larry Wall wrote patch(1)
> that takes the patch and file and applies it.  In a straight line
> history here is how RCS works.  The most recent version of the file
> is stored in whole, the delta behind that is a reverse patch to get
> to that, same for the next delta behind that and so on.
>
> Branches in RCS are forward patches.  Sort of.  You start with the
> whole file that is the most recent version, reverse patch your way
> back to the branch point, and then forward patch your way down to
> the most recent version on the branch.
>
> Yeah, branches in RCS suck, very expensive.
>
> So why is SCCS awesome?  It is an entirely different approach.
> SCCS is a set based system, for any version, there is a set
> of deltas that are in that version and you apply them to the
> file part of the data.
>
> Huh?  What does that mean?  OK, you've all seen SCCS revisions, 1.1,
> 1.2, 1.3, 1.3.1.1, etc.  Yeah, that's for humans (and truth be told those
> revs are not that great).  For SCCS internally there are serial numbers.
> All those are are a monotonically increasing number, doesn't matter
> if you are on the trunk or on a branch, each time you add a delta the
> internal number, or serial, is the last serial plus 1.
>
> When you go to check out a version of the file, that's the set.
> It's the set of serials that make up that file.  If you wanted
> 1.3 and there are no branches, the set is the serial of 1.3 (3)
> and the parent of 1.3 which is 1.2 (2) and 1.1 (1).  So your set
> is 1,2,3.
>
> Here is the awesome part.  The way the data is stored in SCCS
> is nothing like patches, it's what we call a weave.  All versions
> of the file are woven together in the following way.  There are
> 3 operators:
>
> insert: ^AI <serial>
> delete: ^AD <serial>
> end: ^AE <serial>
>
> So if you checked in a file that looked like
>
> I
> love
> TUHS
>
> The weave would be
>
> ^AI 1
> I
> love
> TUHS
> ^AE 1
>
> Lets say that Clem changed that to
>
> I
> really
> love
> TUHS
>
> The new weave would look like:
>
> ^AI 1
> I
> ^AI 2
> really
> ^AE 2
> love
> TUHS
> ^AE 1
>
> and if I changed it to
>
> I
> *really*
> love
> TUHS
>
> the weave looks like
>
> ^AI 1
> I
> ^AD 3
> ^AI 2
> really
> ^AE 2
> ^AE 3
> ^AI 3
> *really*
> ^AE 3
> love
> TUHS
> ^AE 1
>
> So a checkout is 2 things, build up the set of serials that need to be
> active for this checkout, and walk the weave.  For each serial you see
> you are either in this set and I need to do what it says, or this is
> not in my set and I need to do the opposite of what it says.
>
> So that is really really fast compared to RCS.  RCS reads the whole
> file and has to do compute, SCCS reads the whole file and does a
> very tiny fraction of that compute, so tiny that you can't measure
> it compared to reading the file.
>
> But wait, it gets better, much better.  Lets talk about branches
> and merges.  RCS is copy by value across a merge, SCCS is copy by
> reference.  Marc thought about the set stuff enough to realize
> wouldn't be cool if you could manipulate the set.  He added include
> and exclude operators.
>
> Imagine if you and I were having an argument about some video being
> checked in.  You checked it in, I deleted it, you checked it in, I deleted
> it.  Suppose that was a 1GB video.  In RCS, each time we argued that is
> another GB, we did that 4 times, there 4GB of diffs in the history.
>
> In SCCS, you could do that with includes and excludes, those 4 times
> would be about 30 bytes because all they are doing is saying "In the
> set", "Not in the set".
>
> Cool I guess but what is the real life win?  Merges.  In a weave based
> system like SCCS you can add 1GB on a branch and I can merge that onto
> the trunk and all I did was say "include your serials".  I didn't copy
> your work, I referenced it.  Tiny meta data to do so.
>
> That has more implications than you might think.  Think annotations.
> git blame, know that?  It shows who did what?  Yeah, well git is
> copy by value just like RCS.  It's not just about the space used,
> it is also about who did what.  If bwk did one thing and dmr did
> another thing and little old lm merged dmr's stuff into the bwk
> trunk, in a copy by value system, all of dmr's work will look like
> I wrote it in bwk's trunk.
>
> SCCS avoids that.  If I merged dmr's work into bwk's tree, if it
> all automerged, annotations would show it all as dmr's work, yeah,
> I did the merge but I didn't do anything so I don't show up in
> annotations.  If there was a conflict and I had to resolve that
> conflict, then that, and that alone, would show up as my work.
>
> For Marc, I worked with Rick Smith, he found me after I had done a
> reimplentation of SCCS.  He has forgotten more about weaves than I will
> ever know.  But he was really impressed with my code (which you can
> go see at bitkeeper.org, and it is not my code, it is my teams code,
> Rick bugfixed all my mistakes) because I embraced the set thing and the
> way I wrote the code you could have N of my data structures and pulled
> out N versions of the file in one pass.  He had not seen that before,
> to me it just seemed the most natural way to do it.
>
> SCCS is awesome, Marc should be held up as a hero for that.  Most people
> have no idea how much better it is as a format, to this day people still
> do it wrong.  The hg people at facebook sort of got it, they did an
> import of SCCS (it was BitKeeper which is SCCS on super steriods).
> But it is rare that someone gets it.  I wanted Marc to know we got it.
>
> --lm

[TUHS] SCCS

[Larry McVoy]

On Thu, Sep 12, 2019 at 08:49:35AM +1000, Dave Horsfall wrote:
> On Wed, 11 Sep 2019, Larry McVoy wrote:
> 
> >SCCS is awesome, I'll post why in a different thread.  It is light years
> >better than RCS, Tichy lied.
> 
> Agreed; I used it for years, then was forced to use RCS in my next job :-(

Marc Rochkind is on the list, I believe I invited him, but he can spell
check what I'm about to say.

SCCS is awesome.  People have no idea how good it is as a version control
system because Walter Tichy got his PhD for writing RCS and claiming it 
was better (don't get me started on how wrong that was).

Let me start with how RCS works.  You all know about diff and patch,
someone does a diff, produces a patch, and Larry Wall wrote patch(1)
that takes the patch and file and applies it.  In a straight line 
history here is how RCS works.  The most recent version of the file
is stored in whole, the delta behind that is a reverse patch to get 
to that, same for the next delta behind that and so on.

Branches in RCS are forward patches.  Sort of.  You start with the
whole file that is the most recent version, reverse patch your way
back to the branch point, and then forward patch your way down to 
the most recent version on the branch.  

Yeah, branches in RCS suck, very expensive.  

So why is SCCS awesome?  It is an entirely different approach.
SCCS is a set based system, for any version, there is a set
of deltas that are in that version and you apply them to the 
file part of the data.  

Huh?  What does that mean?  OK, you've all seen SCCS revisions, 1.1,
1.2, 1.3, 1.3.1.1, etc.  Yeah, that's for humans (and truth be told those
revs are not that great).  For SCCS internally there are serial numbers.
All those are are a monotonically increasing number, doesn't matter
if you are on the trunk or on a branch, each time you add a delta the
internal number, or serial, is the last serial plus 1.

When you go to check out a version of the file, that's the set.
It's the set of serials that make up that file.  If you wanted
1.3 and there are no branches, the set is the serial of 1.3 (3)
and the parent of 1.3 which is 1.2 (2) and 1.1 (1).  So your set
is 1,2,3.

Here is the awesome part.  The way the data is stored in SCCS
is nothing like patches, it's what we call a weave.  All versions
of the file are woven together in the following way.  There are
3 operators:

insert: ^AI <serial>
delete: ^AD <serial>
end: ^AE <serial>

So if you checked in a file that looked like

I
love
TUHS

The weave would be

^AI 1
I
love
TUHS
^AE 1

Lets say that Clem changed that to

I
really
love
TUHS

The new weave would look like:

^AI 1
I
^AI 2
really
^AE 2
love
TUHS
^AE 1

and if I changed it to

I
*really*
love
TUHS

the weave looks like

^AI 1
I
^AD 3
^AI 2
really
^AE 2
^AE 3
^AI 3
*really*
^AE 3
love
TUHS
^AE 1

So a checkout is 2 things, build up the set of serials that need to be
active for this checkout, and walk the weave.  For each serial you see
you are either in this set and I need to do what it says, or this is
not in my set and I need to do the opposite of what it says.

So that is really really fast compared to RCS.  RCS reads the whole
file and has to do compute, SCCS reads the whole file and does a
very tiny fraction of that compute, so tiny that you can't measure
it compared to reading the file.  

But wait, it gets better, much better.  Lets talk about branches
and merges.  RCS is copy by value across a merge, SCCS is copy by
reference.  Marc thought about the set stuff enough to realize
wouldn't be cool if you could manipulate the set.  He added include
and exclude operators.

Imagine if you and I were having an argument about some video being
checked in.  You checked it in, I deleted it, you checked it in, I deleted
it.  Suppose that was a 1GB video.  In RCS, each time we argued that is
another GB, we did that 4 times, there 4GB of diffs in the history.

In SCCS, you could do that with includes and excludes, those 4 times
would be about 30 bytes because all they are doing is saying "In the
set", "Not in the set".

Cool I guess but what is the real life win?  Merges.  In a weave based
system like SCCS you can add 1GB on a branch and I can merge that onto
the trunk and all I did was say "include your serials".  I didn't copy
your work, I referenced it.  Tiny meta data to do so.

That has more implications than you might think.  Think annotations.
git blame, know that?  It shows who did what?  Yeah, well git is 
copy by value just like RCS.  It's not just about the space used,
it is also about who did what.  If bwk did one thing and dmr did 
another thing and little old lm merged dmr's stuff into the bwk 
trunk, in a copy by value system, all of dmr's work will look like
I wrote it in bwk's trunk.

SCCS avoids that.  If I merged dmr's work into bwk's tree, if it 
all automerged, annotations would show it all as dmr's work, yeah,
I did the merge but I didn't do anything so I don't show up in
annotations.  If there was a conflict and I had to resolve that
conflict, then that, and that alone, would show up as my work.

For Marc, I worked with Rick Smith, he found me after I had done a
reimplentation of SCCS.  He has forgotten more about weaves than I will
ever know.  But he was really impressed with my code (which you can
go see at bitkeeper.org, and it is not my code, it is my teams code,
Rick bugfixed all my mistakes) because I embraced the set thing and the
way I wrote the code you could have N of my data structures and pulled
out N versions of the file in one pass.  He had not seen that before,
to me it just seemed the most natural way to do it.

SCCS is awesome, Marc should be held up as a hero for that.  Most people
have no idea how much better it is as a format, to this day people still
do it wrong.  The hg people at facebook sort of got it, they did an
import of SCCS (it was BitKeeper which is SCCS on super steriods).
But it is rare that someone gets it.  I wanted Marc to know we got it.

--lm