[TUHS] Claim your early Unix contributions on GitHub

[TUHS] Claim your early Unix contributions on GitHub

[Norman Wilson]

Marc Rochkind:

  BSD is the new kind on the block. I don't think it came along until 1977 or
  so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in
  the PWB releases, if you don't count the earlier version in SNOBOL4 for the
  IBM mainframes.

=====

Correct.  We never needed no stinkin' revision control in Research.

More fairly, early systems like SCCS were so cumbersome that a
community that was fairly small, in which everyone talked to
everyone, and in which there was no glaring need wasn't willing
to adopt them.

I remember trying SCCS for a few small personal projects back in
1979 or so (well before I moved to New Jersey), finding it just
too clunky for the benefits it gave me, and giving up.  Much later,
I found RCS just as messy.  One thing that really bugged me was
those systems' inherent belief that you rarely want to keep a
checked-out copy of something except while you're working on it.
Another, harder to work around, is that in any nontrivial project
there are often stages when I want to make changes of scope broader
than a single file: factor common stuff out into a new file, merge
things into a single file, rename files, etc.

CVS was a big step forward, but not enough.  Subversion was the
first revision-control that didn't feel like a huge burden to me.

None of which is to say that SCCS and RCS were useless; they were
important pioneers, and for the big projects that originally
spawned them I'm sure they were indispensible.  But I can't imagine
Ken or Dennis putting up with them for very long, and I'm glad I
never had to.

Norman Wilson
Toronto ON

[TUHS] Claim your early Unix contributions on GitHub

[Ronald Natalie]

> On Mar 30, 2016, at 2:28 PM, Norman Wilson <norman at oclsc.org> wrote:
> 
> Marc Rochkind:
>  One thing that really bugged me was
> those systems' inherent belief that you rarely want to keep a
> checked-out copy of something except while you're working on it.
> Another, harder to work around, is that in any nontrivial project
> there are often stages when I want to make changes of scope broader
> than a single file: factor common stuff out into a new file, merge
> things into a single file, rename files, etc.

Yeah, I hear you.   We wrote wrappers for most of the RCS commands to do checkin and then checkout unlocked.   The EMACS macros were helpful in this because it assumed you worked the way you do (look at a read-only version when not checked out for editing).

We just jumped the version numbers when we needed a common point.

We lived with RCS until we switched to Clearcase.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2284 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/1cb6930b/attachment.bin>

[TUHS] Claim your early Unix contributions on GitHub

[Pat Barron]

On 3/31/2016 5:06 PM, Clem Cole wrote:
> I've rehashed this here before... I'd really like to put this to bed 
> (Dioxides Spinellis -- it would be great if you could put this some 
> where in you files so it does not get lost).
>
>
> I'll restate the history of fsck for my friend and one time lab 
> partner, Ted Kowalski - aka research!frodo or frodo at ece.cmu.edu 
> <mailto:frodo at ece.cmu.edu> as Ted passed a few years ago and can not 
> do this for himself.
>
> [...]

This is really great - thanks from me on this, also!

I missed all of this at CMU by several years.  By the time I got there, 
dvk was at the Software Engineering Institute (which is where I was, so 
that's how I met him), and as far as I am aware, the PDP-11's were 
mostly long gone, except for a few that were used as routers (I had an 
11/34a that we used as our router from the SEI building back to Wean Hall).

Sort of a bummer I missed out on a lot of the fun.  ;-)  I think the 
only thing interesting I did while I was there, Unix-wise, was getting 
the 4.3BSD DEQNA driver working with the DELQA - I gave those changes 
for a few people elsewhere that asked for them, but I can't even find 
them myself anymore....

--Pat.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160401/f37e9188/attachment-0001.html>

[TUHS] Claim your early Unix contributions on GitHub

[Jeremy C. Reed]

On Fri, 1 Apr 2016, Diomidis Spinellis wrote:

> This is the first CSRG fsck SCCS commit.
> 
> Author: Kirk McKusick <mckusick at ucbvax.Berkeley.EDU>
> Date: Thu Aug 27 06:47:37 1981 -0800
> 
> date and time created 81/08/26 23:47:37 by mckusick
> 
> SCCS-vsn: 1.1
> 
> usr/src/sbin/fsck/main.c | 1679

For the earlier code as shipped with BSD see:

4.0 and 4.1  usr/src/cmd/fsck.c
static char *sccsid = "@(#)fsck.c       4.10 (Berkeley) 11/15/80";

The changes document from (January 1980's 3BSD to November 1980's 4BSD) 
calls it the "new ... interactive repair program" and "new, intelligent, 
interactive file system check program" and that it obsoletes dcheck and 
ncheck and largely replaces icheck.

4.1.snap
static  char *sccsid = "@(#)fsck.c      4.13 (Berkeley) 81/03/09";

2.8 (Jun 16  1981 filestamp)
        char    *sccsid = "@(#)fsck.c   2.5";

From those versions it is easy to see that the later main.c derived from 
the fsck.c. (By the time it gets to the version shipped with 4.3BSD

[TUHS] Claim your early Unix contributions on GitHub

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

On Fri, Apr 1, 2016 at 4:01 AM, Diomidis Spinellis <dds at aueb.gr> wrote:

> Thank you Clem!
>
​Most welcome.​




> I added your description of the fsck birth to the repository creation
> source code.
>
​Thank you.​




> I'll also work on injecting the fsck (and SCCS) source code with the
> correct authorship between BSD-3 and BSD-4. Both made their appearance
> during that time via CSRG SCCS.
>
​If I can find and read some old mag tapes with sources, I'll try to get
you earlier dates to put into your records.  I'll take that off line.​




>
> This is the first CSRG fsck SCCS commit.
>
> Author: Kirk McKusick <mckusick at ucbvax.Berkeley.EDU>
> Date: Thu Aug 27 06:47:37 1981 -0800
>

​1981 -- That makes sense...   I would come to UCB in September of '81, but
IIRC wnj had spent the summer before @ research; where Ted spent his
summers also.   Ted had came to CMU in '76 I believe and developed what
would become fsck that year on the EE Digital Lab's 11/34

@ CMU, later in '76, EE & Bio Med got an Unix machine of some flavor, as
did Mellon Institute (which would be the system with the first commercial
UNIX license for a University).     fsck did not make it over to CS to the
11/40e's until later probably '78, likely by dvk who was not EE but common
with me @ Mellon.

I took it with me to Tektronix in '79.    I think Wayne (an CMU EE UNIX
hacker) took his Hawaiian shirts to Cambridge, MA in '78, so that's about
the time it would have made it to MIT.

The important point is that fsck was 4-5 years old by the time it made it
to UCB and was already migrating to other places via sneaker-net.

Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160401/b5a7a695/attachment.html>

[TUHS] Claim your early Unix contributions on GitHub

[Dave Horsfall]

On Thu, 31 Mar 2016, Clem Cole wrote:

> The original FS tools for UNIX icheck/dcheck/ncheck were very crude.

I guess I should mention that somewhere in the AUUGN archives is a paper I 
wrote on the proper use of these tools (after having seen, and made, too 
many mistakes), along with the tool-of-last-resort "clri".

FSCK is a wonderful program, and has saved my bacon many times.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Claim your early Unix contributions on GitHub

[Diomidis Spinellis]

Thank you Clem! I added your description of the fsck birth to the 
repository creation source code. I'll also work on injecting the fsck 
(and SCCS) source code with the correct authorship between BSD-3 and 
BSD-4. Both made their appearance during that time via CSRG SCCS.

This is the first CSRG fsck SCCS commit.

Author: Kirk McKusick <mckusick at ucbvax.Berkeley.EDU>
Date: Thu Aug 27 06:47:37 1981 -0800

date and time created 81/08/26 23:47:37 by mckusick

SCCS-vsn: 1.1

usr/src/sbin/fsck/main.c | 1679
1 file changed, 1679 insertions(+)


Also, these are the first two commits of the SCCS commands.

Author: Bill Joy <root at ucbvax.Berkeley.EDU>
Date: Wed May 14 00:56:00 1980 -0800

date and time created 80/05/13 17:56:00 by root

SCCS-vsn: 1.1

usr/src/local/sccscmds/sccscmds.ok/cmd/delta.c | 670
1 file changed, 670 insertions(+)

commit 5ff237f5a32255288bd826872a309ee844435a1a
Author: Eric Allman <eric at ucbvax.Berkeley.EDU>
Date: Wed Jan 14 22:42:08 1981 -0800

date and time created 81/01/14 14:42:08 by eric

SCCS-vsn: 1.1

usr/src/local/sccscmds/sccscmds.ok/cmd/prs.c | 795
1 file changed, 795 insertions(+)


Diomidis

On 01/04/2016 00:06, Clem Cole wrote:
> I've rehashed this here before... I'd really like to put this to bed
> (Dioxides Spinellis -- it would be great if you could put this some
> where in you files so it does not get lost).

[TUHS] Claim your early Unix contributions on GitHub

[Ron Natalie]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1267 bytes --]

Thanks for that piece of history.   I remember well the days of using icheck and dcheck (coupled with some of the other tools like ncheck and clri…which we rewrote to clrm…much safer because it was easier to reverse if you got the wrong one.     One thing afflicting the V6 file system was that it wasn't too safe in the way it committed changes.   Hence, you could get "dups in free" and  inode link counts that differed from the number of entries in directories.    I remember being grilled on this my freshman year on the file system format, what the various failures were, how to detect them with icheck/dcheck and how to fix them before they'd let me play computer operator on the UNIX system.

FSCK was a big improvement but so was fixing up the ordering in the file system so as not to get degenerate cases (better to lose blocks from the free list than to have them duplicated).

My favorite FSCK story was I was called by an operator one time to tell me that "FSCK had gone into a loop."    When I got there, I found the machine running FSCK on the root, deciding it needed to reboot the machine and doing so and then rerunning FSCK getting the same error.     Somehow the operator neglected to mention that part of the loop was the machine rebooting.

[TUHS] Claim your early Unix contributions on GitHub

[Clem Cole]

I've rehashed this here before... I'd really like to put this to bed (
Dioxides Spinellis -- it would be great if you could put this some where in
you files so it does not get lost).


I'll restate the history of fsck for my friend and one time lab partner,
Ted Kowalski - aka research!frodo or frodo at ece.cmu.edu as Ted passed a few
years ago and can not do this for himself.

Ted did his undergrad at Michigan and was Bill Joy's housemate (where wnj
was also an undergrad) in the early 1970s.  Both were MTS/360 hackers and
were introduced to UNIX there.    Ted would go to CMU for his grad work in
the mid/late 1970s (where I knew him when I was there) and Joy would do his
grad work at UCB in the same time frame (as did I were I knew him).  I
was originally a CMU TSS/360 [MTS's older brother] hacker and was
introduced to UNIX by Ted.***



The original FS tools for UNIX icheck/dcheck/ncheck were very crude.  TSS
and MTS (used a similar/same FS format) and and had a similar program in
the key of fsck that Ted was familiar (as did a number of DEC systems for
that matter).    Ted wrote the original version of premordial fsck for v6
at UMich (maybe v5 - Joy probably would know what the version of UNIX was
there then).

Ted took "pre-fsck" to Bell Lab the summer between Mich and CMU.     Ted
would rewrite and "continue hacking" fsck at CMU in the next year targeting
V6.   It was at this time that CMU was switching from V5 to V6, I do not
believe (remember) that Ted ever had fsck running on a V5 format FS, but
early versions could definitely be compiled for either v6 or v7 with
#ifdefs (I'm likely to have those sources somewhere if I can read a tape --
but I can tell you the bits were not in SCCS control).  I remember taking
his ire when we both edited a file at the same time ;-)

BTW: the reason why the errors from the original version of fsck were all
in UPPER CASE was because that's TSS and MTS did that.  So that's how I was
taught for sure and I believe Ted also.   A number of early CMU UNIX
programs look this way.

Note:  Ted was *originally* in the "UNIX Support Group" @ BTL - aka USG
(summit, not research and IIRC was Armando's officemate at USG).  By the
early 1980s, Ted would become part of Research, so the research!frodo
moniker became his (although I can not state when that was but other might
know).

When Ted (and Armando) were part of USB ???1977 or 78 maybe?? working on a
kernel referred to as UNIX/TS - which would later become the kernel release
by USG in PWB 2.0.  UNIX/TS was loosely based on bits that Ken and Dennis
were working with in Murray Hill - but the kernel and FS difference between
v6 and v7 were in UNIX/TS (PWB 2.0 et els).

At some point (June I think) Dennis (and the research folks) took a snap
shot of what was the research in 1979.  This would be released the folks
outside of BTL as V7.    Ted had not yet completed fsck and so it was not
(yet) in the research system (*i.e.* they still used
icheck/ncheck/dcheck).  But Ted would later put it into what would become
PWB 2.0.


Similarly, Ted would also give copies of the CMU program to Ken/Dennis,
Bill, and Armando for sure and I suspect some of his other friends at UMich
had it also.  I had done some >>small<< things to help him with the program
during my CMU time so I had it (it was how I learned C after being an
assembler, Bliss, Algol and SAIL hacker from the TSS, 10s and VMS).

Those of us UNIX hackers from CMU are also likely to have had fsck such as
dvk (CS),  gss (BIO), tron(Mellon), and others (for instance, I believe
Wayne Gramlich who was gss's housemate in Pittsburgh brought fsck from CMU
to MIT when he moved from undergrad @ CMU to grad student at MIT - again
someone like Noah might know when it showed up there).

The point is that fsck was officially a "CMU/EE Dept developed program"  -
although frodo certainly used UMich, as well as AT&T resources at USG
hacking on it also.  But because of the CMU origins it was able to swim the
UNIX oceans independently of the AT&T distribution methods of either
research or summit.  For instance, I brought it to Tektronix before I was
at UCB and it was at UCB by the time I was there.

I suspect it was Joy who put it into BSD at some point, although there was
definitely a number of students and faculty starting with Ken that moved
between BTL and UCB (i.e. any BTL "OYOC" student could have
brought anything with them); much less common students between CMU/UCB such
as myself, Mike Carey, Shafi Goldwasser just in my class but as I said I
think it predates us there.  I would have expected fsck to become part of
BSD around 3.0 but it might not have been until 4.0 or 4.1.   Also any SCCS
files you have from Joy/Kirk, are a number of years later than the original
development.  They are based on the version wnj would have gotten from Ted
at some point.

How it made it to DEC, I do not know, although there were enough folks from
lots of places like BTL much less academic institutions such as CMU
(including Gordon Bell who was one of our Profs, Dave Roger's who ran the
Vax project, Sam Fuller, and Bell's student Bell Strecker), that went to
DEC that it's not surprising fsck made it there too.

Clem


***A side note, while Multics/CTSS impacted the BTL & MIT folks, and
untold story
of UNIX history is how TSS, MTS and VM/CMS for the IBM 360 had  impact on
many for the UNIX hackers of that same time from other academic centers
(CMU, MIT, Stanford, Cornell, Princeton ...).

On Wed, Mar 30, 2016 at 11:14 AM, Pat Barron <patbarron at acm.org> wrote:

> On 3/30/2016 11:49 AM, Diomidis Spinellis wrote:
>
>>
>> Other commands that fall into this category include fsck (frodo), gres
>> (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has commented on
>> this list that a secret tunnel linked Murray Hill and Berkeley. I'd welcome
>> any better explanations you may have.
>>
>
> FWIW, "fsck" existed in V7m (from DEC) as well, though I'm not sure it was
> necessarily the same program....
>
> --Pat.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160331/75dda3c9/attachment-0001.html>

[TUHS] Claim your early Unix contributions on GitHub

[Larry McVoy]

On Thu, Mar 31, 2016 at 01:42:23AM +0200, Joerg Schilling wrote:
> Larry McVoy <lm at mcvoy.com> wrote:
> 
> > > Given that using git enforces a loss of meta data, is there a chance to get 
> > > the SCCS history for older UNIX versions?
> >
> > You are the first person outside of BitMover that I've ever seen
> > recognize that.  Go you!  It's very annoying, we can write a perfect BK
> > to Git exporter but going the other way is a research project.
> 
> We talked about this before: You are the only person who does not attack me 
> when I write that SCCS is much faster than RCS, just because you know ;-)

You can thank Walter Tichy, who got a PhD for RCS if I recall, can you
believe that?  He tried to paint SCCS as bad and everyone believed him.

SCCS is brilliant in how it stores the changes, it's a weave rather than
diff and patch.  Which means it can get 1.1 as fast as it can get the tip.
Or better put, in a big tree, it is way way faster than git for some things:

What                      BK              GIT         How much faster is BK?
----------------------------------------------------------------------------
annotate/blame        0.01 seconds     32.3 seconds        3230 times faster
search history        0.01 seconds    138.9 seconds       13890 times faster

That's a 1M changeset tree with 230,000 files (4GB of history).  You all
know what annotate/blame are, the search history is answering the question
"did the string 'those bastards at $COMPANY' ever occur in our source code?"
so it's searching all versions.  The SCCS weave is instant for stuff like 
that; diff and patch have to tons more work.

> The first system to implement something based on previous good ideas was BK and 

We took the weave and turbo charged it.  Recent BK versions are crazy fast.

> AFAIK, GIT was implemented originally as an empty shelf that aimed to imitate 
> the CLI from BK.

No, Git, credit to Linus, was his own ideas.  Yeah, he took the basic model
of clone/pull/commit/push, but the storage format is all his (and retarded,
it doesn't scale, it's all content addressable data by hash, works when it
fits in memory, thrashes like hell when it doesn't).  

Anyhoo, we should take this private, this is a Unix list, not an SCM list.
Though I am loving the work to get a repo, even if it is git, with all
the history.  That's awesome!

[TUHS] Claim your early Unix contributions on GitHub

[Larry McVoy]

On Wed, Mar 30, 2016 at 11:34:08PM -0400, Random832 wrote:
> On Wed, Mar 30, 2016, at 23:20, Larry McVoy wrote:
> > On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote:
> > > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote:
> > > > You are the first person outside of BitMover that I've ever seen
> > > > recognize that.  Go you!  It's very annoying, we can write a perfect BK
> > > > to Git exporter but going the other way is a research project.
> > > 
> > > Didn't you sue someone for writing a BK to Git exporter?
> > 
> > Nope.  In 18 years of business we've never sued anyone.
> 
> Sorry, I guess I got the timeline and the specifics mixed up (the stuff
> about a non-compete agreement - I've never heard of any other company
> having such a thing for their _customers_ - made me assume that there
> was an attempt to actually enforce that), but it certainly seemed like
> you were not very big fans of the idea of a perfect BK-to-_anything_
> exporter, since then you'd lose control of the users whose metadata you
> had locked up in your servers.

Dear Mr or Ms Random832, 

The BK flame wars are long gone, Git won.  Not really interested in 
rehashing all of that.  Especially not here.  Please take your ax
and grind it elsewhere if that is what you want to do.

To the rest of the list, sorry about this, not my intent to have these
"discussions" here.

--lm

[TUHS] Claim your early Unix contributions on GitHub

[Random832]

On Wed, Mar 30, 2016, at 23:20, Larry McVoy wrote:
> On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote:
> > On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote:
> > > You are the first person outside of BitMover that I've ever seen
> > > recognize that.  Go you!  It's very annoying, we can write a perfect BK
> > > to Git exporter but going the other way is a research project.
> > 
> > Didn't you sue someone for writing a BK to Git exporter?
> 
> Nope.  In 18 years of business we've never sued anyone.

Sorry, I guess I got the timeline and the specifics mixed up (the stuff
about a non-compete agreement - I've never heard of any other company
having such a thing for their _customers_ - made me assume that there
was an attempt to actually enforce that), but it certainly seemed like
you were not very big fans of the idea of a perfect BK-to-_anything_
exporter, since then you'd lose control of the users whose metadata you
had locked up in your servers.

[TUHS] Claim your early Unix contributions on GitHub

[Larry McVoy]

On Wed, Mar 30, 2016 at 05:07:29PM -0400, Random832 wrote:
> On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote:
> > You are the first person outside of BitMover that I've ever seen
> > recognize that.  Go you!  It's very annoying, we can write a perfect BK
> > to Git exporter but going the other way is a research project.
> 
> Didn't you sue someone for writing a BK to Git exporter?

Nope.  In 18 years of business we've never sued anyone.

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Larry McVoy <lm at mcvoy.com> wrote:

> > Given that using git enforces a loss of meta data, is there a chance to get 
> > the SCCS history for older UNIX versions?
>
> You are the first person outside of BitMover that I've ever seen
> recognize that.  Go you!  It's very annoying, we can write a perfect BK
> to Git exporter but going the other way is a research project.

We talked about this before: You are the only person who does not attack me 
when I write that SCCS is much faster than RCS, just because you know ;-)

RCS was not a advantage for the developer community as it's use was based on a 
missunderstanding of properties.

The first system to implement something based on previous good ideas was BK and 
AFAIK, GIT was implemented originally as an empty shelf that aimed to imitate 
the CLI from BK.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Random832 <random832 at fastmail.com> wrote:

> On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote:
> > You are the first person outside of BitMover that I've ever seen
> > recognize that.  Go you!  It's very annoying, we can write a perfect BK
> > to Git exporter but going the other way is a research project.
>
> Didn't you sue someone for writing a BK to Git exporter?

Doesn't GIT use a similar import format as BK uses for it's output?

AFAIK, GIT was written as a BK CLI clone.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Random832]

On Wed, Mar 30, 2016, at 15:17, Larry McVoy wrote:
> You are the first person outside of BitMover that I've ever seen
> recognize that.  Go you!  It's very annoying, we can write a perfect BK
> to Git exporter but going the other way is a research project.

Didn't you sue someone for writing a BK to Git exporter?

[TUHS] Claim your early Unix contributions on GitHub

[Larry McVoy]

On Wed, Mar 30, 2016 at 02:31:21PM +0200, Joerg Schilling wrote:
> Diomidis Spinellis <dds at aueb.gr> wrote:
> 
> > The Unix History repository on GitHub [1] aims to provide the evolution 
> > of Unix from the 1970s until today under Git revision control.  Through 
> > a few changes recently made [2] it's now possible for individual 
> > contributors to have their GitHub profile linked to their early Unix 
> > contributions.  Ken Thompson graciously made this move last week 
> > following a personal email invitation.  I think it would be really cool 
> > if more followed.  This would send a powerful message of continuity and 
> > tradition in computing to youngsters joining GitHub today.
> 
> Given that using git enforces a loss of meta data, is there a chance to get 
> the SCCS history for older UNIX versions?

You are the first person outside of BitMover that I've ever seen
recognize that.  Go you!  It's very annoying, we can write a perfect BK
to Git exporter but going the other way is a research project.

--larry "not feeling love for git" mcvoy

[TUHS] Claim your early Unix contributions on GitHub

[Larry McVoy]

On Wed, Mar 30, 2016 at 05:23:00PM +0200, Joerg Schilling wrote:
> I am not sure whether there ever was something like user at domain in version 
> control before BitKeeper SCCS has been introduced.

Pretty sure we were first with it.  We didn't have it in Sun's SCCS.

[TUHS] Claim your early Unix contributions on GitHub

[John Cowan]

Marc Rochkind scripsit:

> BSD is the new kind on the block. I don't think it came along until 1977 or
> so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in
> the PWB releases, if you don't count the earlier version in SNOBOL4 for the
> IBM mainframes.

Are any PWB releases publicly available?  Though they aren't explicitly
enumerated by the 2002 Caldera license, there's surely no one left with
standing to object to its publication today.

-- 
John Cowan          http://www.ccil.org/~cowan        cowan at ccil.org
Reversing the apostolic precept to be all things to all men, I usually [before
Darwin] defended the tenability of the received doctrines, when I had to do
with the [evolution]ists; and stood up for the possibility of [evolution] among
the orthodox --thereby, no doubt, increasing an already current, but quite
undeserved, reputation for needless combativeness.  --T. H. Huxley

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

Marc Rochkind <rochkind at basepath.com> wrote:

> BSD is the new kind on the block. I don't think it came along until 1977 or
> so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in
> the PWB releases, if you don't count the earlier version in SNOBOL4 for the
> IBM mainframes.

I guess that SCCSv3 with binary history files (used before 1977) was written 
in C already, correct?

I have never been able to find any SCCS sources that predate the conversion to
text history files in 1977. So I guess that before 1977, SCCS was only used 
internally at AT&T.


Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Marc Rochkind]

BSD is the new kind on the block. I don't think it came along until 1977 or
so. Research UNIX I don't think picked up SCCS ever. SCCS first appeared in
the PWB releases, if you don't count the earlier version in SNOBOL4 for the
IBM mainframes.

--Marc



On Wed, Mar 30, 2016 at 9:49 AM, Diomidis Spinellis <dds at aueb.gr> wrote:

> On 30/03/2016 17:25, Marc Rochkind wrote:
>
>> What do you mean by "early"? All of my early work was done under my
>> login "marc", and in those days to email we just typed:
>>
>> % mail marc
>>
>> Email was internal to the system. Email between machines came along later.
>>
>> Also, I don't think we ever used the word "commit." Actually, much of my
>> early work predated the introduction of SCCS. ;-)
>>
>
> I should have been more clear. The Unix history Git repository contains
> synthetic commits imported from snapshots, patches, SCCS, CVS, and Git
> files. I took the liberty of attaching the email ID at research.uucp on all
> Bell Labs commits, even though many predate UUCP email.
>
> Your SCCS work belongs to the mysterious subset of Bell Labs commands that
> made their first public appearance on BSD Unix. I didn't find SCCS included
> in the 6th or 7th Research Edition, nor in Unix 32/V, which, I understand,
> were the ancestors of BSD.
>
> Specifically, I first find SCCS included in the BSD-4 snapshot (e.g.
> usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating BSD-4,
> through commits such as the following.
>
> commit 20f9634be56fa471a34bc386dcc4c04f9587791d
> Author: Eric Allman <eric at ucbvax.Berkeley.EDU>
> Date: Tue May 13 07:23:29 1980 -0800
>
> changed path to SCCS/s.
> added chghist & help
> generalized argument chomping
>
> SCCS-vsn: 1.2
>
>
> Other commands that fall into this category include fsck (frodo), gres
> (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has commented on
> this list that a secret tunnel linked Murray Hill and Berkeley. I'd welcome
> any better explanations you may have.
>
>
> I'll find a way to graft you as the developer of SCCS somewhere between
> BSD3 and BSD4, so please do claim marc at research.uucp on GitHub.  Are
> there other files I should also attribute to you?
>
>
> Diomidis
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/8a6c5175/attachment.html>

[TUHS] Claim your early Unix contributions on GitHub

[Diomidis Spinellis]

On 30/03/2016 19:07, Joerg Schilling wrote:
> It seems that you confuse the program "sccs" from Eric Allman with SCCS in
> general.
[...]
> CSRG includes the UCB history for the AT&T SCCS commands as well, but they have
> not been legally available before December 20 2006. The AT&T sources "slipped"
> into the CSRG archives and nobody really complained ;-)

Thank you for the clarification!  The AT&T SCCS commands appear to have 
been put under SCCS control at CSRG in 1981, again mostly by Eric Allman.

commit 92fe3a3649e9adbf1e06346b5fe09f57e7b8017f
Author: Eric Allman <eric at ucbvax.Berkeley.EDU>
Date:   Wed Jan 14 22:42:08 1981 -0800

     date and time created 81/01/14 14:42:08 by eric

     SCCS-vsn: 1.1

  usr/src/local/sccscmds/sccscmds.2/cmd/prs.c | 795 
++++++++++++++++++++++++++++
  1 file changed, 795 insertions(+)

[TUHS] Claim your early Unix contributions on GitHub

[Pat Barron]

On 3/30/2016 11:49 AM, Diomidis Spinellis wrote:
>
> Other commands that fall into this category include fsck (frodo), gres 
> (lem), efl (sif), diction (llc), and ideal (cvw). Somebody has 
> commented on this list that a secret tunnel linked Murray Hill and 
> Berkeley. I'd welcome any better explanations you may have.

FWIW, "fsck" existed in V7m (from DEC) as well, though I'm not sure it 
was necessarily the same program....

--Pat.

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]

Diomidis Spinellis <dds at aueb.gr> wrote:

> Specifically, I first find SCCS included in the BSD-4 snapshot (e.g. 
> usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating 
> BSD-4, through commits such as the following.
>
> commit 20f9634be56fa471a34bc386dcc4c04f9587791d
> Author: Eric Allman <eric at ucbvax.Berkeley.EDU>
> Date: Tue May 13 07:23:29 1980 -0800
>
> changed path to SCCS/s.
> added chghist & help
> generalized argument chomping

It seems that you confuse the program "sccs" from Eric Allman with SCCS in 
general.

sccs	see: http://sccs.sourceforge.net/man/sccs.1.html
	is a wrapper program that helps to use the SCCS worker programs.
	"sccs" was written at UC Berkeley since Max 10 1980.

	Check the bottom SEE ALSO paragraph.

admin cdc comb delta get help prs prt rmdel sact unget val
	are the worker programs that predate the existence of the "sccs"
	program by many years.
	These programs have been written at AT&T by Marc.

BTW: The SCCSv4 history format was introduced February 18, 1977 and is still
understood by recent software.

CSRG includes the UCB history for the AT&T SCCS commands as well, but they have 
not been legally available before December 20 2006. The AT&T sources "slipped"
into the CSRG archives and nobody really complained ;-)

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Diomidis Spinellis]

On 30/03/2016 17:25, Marc Rochkind wrote:
> What do you mean by "early"? All of my early work was done under my
> login "marc", and in those days to email we just typed:
>
> % mail marc
>
> Email was internal to the system. Email between machines came along later.
>
> Also, I don't think we ever used the word "commit." Actually, much of my
> early work predated the introduction of SCCS. ;-)

I should have been more clear. The Unix history Git repository contains 
synthetic commits imported from snapshots, patches, SCCS, CVS, and Git 
files. I took the liberty of attaching the email ID at research.uucp on all 
Bell Labs commits, even though many predate UUCP email.

Your SCCS work belongs to the mysterious subset of Bell Labs commands 
that made their first public appearance on BSD Unix. I didn't find SCCS 
included in the 6th or 7th Research Edition, nor in Unix 32/V, which, I 
understand, were the ancestors of BSD.

Specifically, I first find SCCS included in the BSD-4 snapshot (e.g. 
usr.bin/sccs/sccs.c) and also in the BSD SCCS repositories predating 
BSD-4, through commits such as the following.

commit 20f9634be56fa471a34bc386dcc4c04f9587791d
Author: Eric Allman <eric at ucbvax.Berkeley.EDU>
Date: Tue May 13 07:23:29 1980 -0800

changed path to SCCS/s.
added chghist & help
generalized argument chomping

SCCS-vsn: 1.2


Other commands that fall into this category include fsck (frodo), gres 
(lem), efl (sif), diction (llc), and ideal (cvw). Somebody has commented 
on this list that a secret tunnel linked Murray Hill and Berkeley. I'd 
welcome any better explanations you may have.


I'll find a way to graft you as the developer of SCCS somewhere between 
BSD3 and BSD4, so please do claim marc at research.uucp on GitHub.  Are 
there other files I should also attribute to you?


Diomidis

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

Marc Rochkind <rochkind at basepath.com> wrote:

> What do you mean by "early"? All of my early work was done under my login
> "marc", and in those days to email we just typed:
>
> % mail marc
>
> Email was internal to the system. Email between machines came along later.
>
> Also, I don't think we ever used the word "commit." Actually, much of my
> early work predated the introduction of SCCS. ;-)

Good point!

Checking the sccs -R log output from the CSRG archives of course at the bottom
gives something like: 

Wed Apr  9 16:02:50 1980 bill
        * ./sys/kern/kern_resource.c 3.1
          date and time created 80/04/09 16:02:50 by bill

Wed Apr  9 16:02:48 1980 bill
        * ./sys/vax/vax/Locore.c 3.1
          date and time created 80/04/09 16:02:48 by bill

Tue Dec  4 15:58:14 1979 bostic
        * ./usr.bin/ctags/ctags.c 4.1
          3bsd version


and we need to know that "bostic" is the login from Keith Bostic and "bill" is 
the login from Bill Joy.

I am not sure whether there ever was something like user at domain in version 
control before BitKeeper SCCS has been introduced.

BTW: the introduction of SCCS was early, at that time I had no access to more 
than a desktop calculator.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Marc Rochkind]

What do you mean by "early"? All of my early work was done under my login
"marc", and in those days to email we just typed:

% mail marc

Email was internal to the system. Email between machines came along later.

Also, I don't think we ever used the word "commit." Actually, much of my
early work predated the introduction of SCCS. ;-)

marc

On Wed, Mar 30, 2016 at 1:53 AM, Diomidis Spinellis <dds at aueb.gr> wrote:

> The Unix History repository on GitHub [1] aims to provide the evolution of
> Unix from the 1970s until today under Git revision control.  Through a few
> changes recently made [2] it's now possible for individual contributors to
> have their GitHub profile linked to their early Unix contributions.  Ken
> Thompson graciously made this move last week following a personal email
> invitation.  I think it would be really cool if more followed.  This would
> send a powerful message of continuity and tradition in computing to
> youngsters joining GitHub today.
>
> What you need to do is the following.
>
> - Create a GitHub profile (if you haven't already got one)
> - Click on https://github.com/settings/emails
> - Add the email address(es) associated with your early Unix commits (e.g.
> foo at research.uucp or bar at ucbvax.berkeley.edu). You can easily find an
> author's commits and email addresses recorded in the repository through the
> web search form http://www.spinellis.gr/cgi-bin/namegrep.pl
> - GitHub will tell you that a verification email has been sent to your
> (probably defunct) email address.  Don't worry.  Your account will be
> linked to the address even without the verification step.
> - Adding your photograph to your profile will increase the vividness of
> GitHub's revision listings.
>
> If you're in contact with Unix contributors who are not on this list,
> please forward them this message.  Also, if your name isn't properly
> associated with the repository's commits, drop me an email message (or a
> GitHub pull request for the corresponding file [3]), and I'll add it.
>
> [1] https://github.com/dspinellis/unix-history-repo
> [2] The modifications involved the change of UUCP addresses to use the
> .uucp pseudo-domain rather than a ! path and the listing of co-authors
> within the commit message.
> [3]
> https://github.com/dspinellis/unix-history-make/tree/master/src/author-path
>
> Diomidis - http://www.spinellis.gr
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20160330/40365f37/attachment.html>

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2626 bytes --]

Diomidis Spinellis <dds at aueb.gr> wrote:

> On 30/03/2016 15:31, Joerg Schilling wrote:
> > Given that using git enforces a loss of meta data, is there a chance to get
> > the SCCS history for older UNIX versions?
>
> I've tried to incorporate the SCCS meta data in the Git commits.  Where 
> that was not possible I added a header-like line in the Git commit message.
>
> The BSD CSRG SCCS data are available on the four CD set compiled by 
> Marshall Kirk McKusick https://www.mckusick.com/csrg/.
>
> I don't know of any other SCCS data openly available.  If anyone has 
> such data, I'd appreciate a copy.

I know of no other SCCS data, but let me make a remark that results from a 
recent discussion with Kirk Mckusick:

Kirk told me that the regents of UCB do not like the unmodified (original) SCCS 
history data to be published unless this is done with a written permission.
Currently only Kirk owns such a permission.

Kirk did however aks whether the GIT repo from CSRG would be OK as it contains 
hand made fixes for a disk crash and as it does not use the original meta data.
The result was that there is no problem with a different archive format.

Given that the recent (upcomming **) SCCS history format (SCCSv6) is not the 
original SCCSv4 format that was used in CSRG, it seems that using the hand 
crafted fixed and a conversion to SCCSv6 would be OK as well.

The advantage with the SCCSv6 history format is that you are able to convert it 
back to the SCCSv4 history format via:

	sccs -R cvt -d -V4 .

;-)

I am planning a SCCSv6 variant of the CSRG archives, but I need to manually fix 
the broken history files first. Note that this now may be a bit easier because

	sccs -R val -T

gives better warnings since a few years than the historic sccs did.


Note that a full SCCS history may be very helpful. Last year, I came up with 
some problems in the Bourne Shell and a SCCS history with delta comments from 
around 1983 would have been very helpful to understand some changes that 
introduced bugs.

I also recently was interested in knowing when waitpid() was introduced.

**) upcomming because support for project based commits and network support is 
not yet ready in sccs.

See http://sccs.sourceforge.net/man/sccsfile.4.html for a description of the 
SCCSv6 history format.

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Diomidis Spinellis]

On 30/03/2016 15:31, Joerg Schilling wrote:
> Given that using git enforces a loss of meta data, is there a chance to get
> the SCCS history for older UNIX versions?

I've tried to incorporate the SCCS meta data in the Git commits.  Where 
that was not possible I added a header-like line in the Git commit message.

The BSD CSRG SCCS data are available on the four CD set compiled by 
Marshall Kirk McKusick https://www.mckusick.com/csrg/.

I don't know of any other SCCS data openly available.  If anyone has 
such data, I'd appreciate a copy.

[TUHS] Claim your early Unix contributions on GitHub

[Joerg Schilling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

Diomidis Spinellis <dds at aueb.gr> wrote:

> The Unix History repository on GitHub [1] aims to provide the evolution 
> of Unix from the 1970s until today under Git revision control.  Through 
> a few changes recently made [2] it's now possible for individual 
> contributors to have their GitHub profile linked to their early Unix 
> contributions.  Ken Thompson graciously made this move last week 
> following a personal email invitation.  I think it would be really cool 
> if more followed.  This would send a powerful message of continuity and 
> tradition in computing to youngsters joining GitHub today.

Given that using git enforces a loss of meta data, is there a chance to get 
the SCCS history for older UNIX versions?

Jörg

-- 
 EMail:joerg at schily.net                  (home) Jörg Schilling D-13353 Berlin
       js at cs.tu-berlin.de                (uni)  
       joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/

[TUHS] Claim your early Unix contributions on GitHub

[Diomidis Spinellis]

The Unix History repository on GitHub [1] aims to provide the evolution 
of Unix from the 1970s until today under Git revision control.  Through 
a few changes recently made [2] it's now possible for individual 
contributors to have their GitHub profile linked to their early Unix 
contributions.  Ken Thompson graciously made this move last week 
following a personal email invitation.  I think it would be really cool 
if more followed.  This would send a powerful message of continuity and 
tradition in computing to youngsters joining GitHub today.

What you need to do is the following.

- Create a GitHub profile (if you haven't already got one)
- Click on https://github.com/settings/emails
- Add the email address(es) associated with your early Unix commits 
(e.g. foo at research.uucp or bar at ucbvax.berkeley.edu). You can easily find 
an author's commits and email addresses recorded in the repository 
through the web search form http://www.spinellis.gr/cgi-bin/namegrep.pl
- GitHub will tell you that a verification email has been sent to your 
(probably defunct) email address.  Don't worry.  Your account will be 
linked to the address even without the verification step.
- Adding your photograph to your profile will increase the vividness of 
GitHub's revision listings.

If you're in contact with Unix contributors who are not on this list, 
please forward them this message.  Also, if your name isn't properly 
associated with the repository's commits, drop me an email message (or a 
GitHub pull request for the corresponding file [3]), and I'll add it.

[1] https://github.com/dspinellis/unix-history-repo
[2] The modifications involved the change of UUCP addresses to use the 
.uucp pseudo-domain rather than a ! path and the listing of co-authors 
within the commit message.
[3] 
https://github.com/dspinellis/unix-history-make/tree/master/src/author-path

Diomidis - http://www.spinellis.gr