Larry,

I have been out of working (retired from AT&T Labs Research in 2013), let alone working on SCCS and related tools for quite a while.
I'm happy to hear that some folks appreciated what I called "INEX" (for include/exclude); one of my contributions to SCCS.
I've had to argue against RCS and, of course, deal with CVS, much to my chagrin.
Are you familiar with the concept of SCCS ID lists (slists), which act as a table of contents of a "unit" (usually a library or load module)?
Not much released (from the Labs) documentation on slists; one paper was way back in COMSAC 80 by three former co-workers: Gene Cristofor, Tim Wendt and Bud Wonsiewicz.

Alan

P.S. Sounds like I should learn more about BitKeeper.


On Fri, Nov 19, 2021 at 3:14 PM Larry McVoy <lm@mcvoy.com> wrote:
All the time.  A merge in BitKeeper (which is SCCS based, I rewrote SCCS
from scratch and evolved it quite a bit) is just a

get -e -ir1,r2,r3,r4

where the include list is all the revs on the branch being merged.

That's the beauty of SCCS that seems to be lost to the rest of the
world:  if someone added N bytes on the branch, the merge passes that
to the trunk by *reference*, every other SCM that is in current use
copies the branch data to the trunk.

Suppose Rob had done a bunch of important work on the branch, you had
done some work on the trunk, and for whatever reason, I merged Rob's
work.  Let's say everything automerged.  In SCCS or BitKeeper, the only
new data in the file is a merge node that says "Include all of Rob's
work".  In all other systems in use today, there would be a merge node
with another copy of Rob's work with me as the author because I did
the merge.  Blech.

Strangely enough, ClearCase has a weave format like SCCS and they could
have done merges by reference and they choose to copy it.  I dunno who
the idiot was that made that decision.

On Fri, Nov 19, 2021 at 03:04:37PM -0500, Alan Glasser wrote:
> Larry,
>
> Did you ever try the -i or -x options on get(1) to include or exclude
> deltas?
>
> Alan
>
>
> On Wed, Nov 17, 2021 at 7:39 PM Larry McVoy <lm@mcvoy.com> wrote:
>
> > I'll defend perl, at least perl4, vigorously.  I wrote a lot of code in
> > it on 20mhz SPARCs.  Yeah, like any kitchen sink language you have to
> > develop a style, but it is possible.  All of Solaris 2.0 development
> > happened under a source management system I wrote, NSElite, that was
> > almost 100% perl4.  There was one C program, that Marc might like,
> > that took 2 SCCS files that had the initial part of the graph in
> > common but the recent nodes were different in each file, and zippered
> > them together into a new SCCS file that had the newer nodes on a
> > branch.  It was F.A.S.T compared to the edit/delta cycles you'd
> > do if you did it by hand.
> >
> > My perl4 was maintainable, I fixed bugs in it quickly.
> >
> > When it happened, perl4 was a God send, as much as I love awk, perl
> > was far more useful for stuff that awk just didn't want to handle.
> >
> > On Thu, Nov 18, 2021 at 09:21:49AM +1100, Rob Pike wrote:
> > > Perl certainly had its detractors, but for a few years there it was the
> > > lingua franca of system administration.
> > >
> > > -rob
> > >
> > >
> > > On Thu, Nov 18, 2021 at 8:21 AM Dan Cross <crossd@gmail.com> wrote:
> > >
> > > > On Wed, Nov 17, 2021 at 3:54 PM Warner Losh <imp@bsdimp.com> wrote:
> > > >
> > > >> On Wed, Nov 17, 2021, 1:48 PM Dan Stromberg <drsalists@gmail.com>
> > wrote:
> > > >>
> > > >>> On Wed, Nov 17, 2021 at 11:35 AM Norman Wilson <norman@oclsc.org>
> > wrote:
> > > >>>
> > > >>>> Wasn't Perl created to fill this void?
> > > >>>>
> > > >>>> Void? I thought Perl was created to fill a much-needed gap.
> > > >>>>
> > > >>> There was and is a need for something to sit between Shell and C.
> > But
> > > >>> it needn't be filled by Perl.
> > > >>>
> > > >>> The chief problem with Perl, as I see it, is it's like 10 languages
> > > >>> smashed together.  To write it, you only need to know one of the
> > 10.  But
> > > >>> to read it, you never know what subset you're going to see until
> > you're
> > > >>> deep in the code.
> > > >>>
> > > >>> Perl is the victim of an experiment in exuberant, Opensource design,
> > > >>> where the bar to adding a new feature was troublingly low.
> > > >>>
> > > >>> It was undeniably influential.
> > > >>>
> > > >>
> > > >> It's what paved the way for python to fill that gap...
> > > >>
> > > >
> > > > I feel that Perl, and to a lesser extent Tcl, opened the floodgates
> > for a
> > > > number of relatively lightweight "scripting" languages that sat
> > between C
> > > > and the shell in terms of their functionality and expressive power.
> > From
> > > > that group, the one I liked best was Ruby, but it got hijacked by
> > Rails and
> > > > Python swooped in and stole its thunder.
> > > >
> > > >         - Dan C.
> > > >
> > > >
> >
> > --
> > ---
> > Larry McVoy                  lm at mcvoy.com
> > http://www.mcvoy.com/lm
> >

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