The Unix Heritage Society mailing list
 help / color / Atom feed
From: Clem Cole <clemc@ccc.com>
To: Larry McVoy <lm@mcvoy.com>,
	"tuhs@minnie.tuhs.org" <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] SCCS
Date: Thu, 12 Sep 2019 10:35:32 -0400
Message-ID: <CAC20D2Pk2F-pb5_0kxT-5TNeZk--d27wHE_-AR09dXcPZbHyTA@mail.gmail.com> (raw)
In-Reply-To: <03956472-B6A1-4E83-B2F1-0FE855C75C15@jctaylor.com>

[-- 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 --]

<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thus, I think it comes back to <u><i>use case</i></u> for everyone.  What am I protecting with this subsystem and how does it affect me?</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 &#39;behind my back&#39;(important); how merges are handled when I&#39;m in a group setting; and IF AND ONLY IF I&#39;m using the tool kit to protect IP for a &#39;product&#39;, how easy it is to support &#39;releases&#39; past/current/in-development at the same time.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">The truth is, when I&#39;m leading product development, that last one moves up a few places, although I know that if the &#39;fit&#39; 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 &#39;ease of use&#39; as the most important <span style="font-family:Roboto,arial,sans-serif;font-size:16px">attribute</span> for me.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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&#39;s &quot;sccs(ucb)&quot; front-end &#39;fixed&#39; the harder to use part of things.  Frankly, I have aliases &#39;get&#39; to be &#39;sccs get&#39; and the like.  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">I was at Tektronix and like many when Tichey released RCS by itself, Eric&#39;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&#39;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. </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 ;-) </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"> </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Since that time, I have been given Mercurial, SVN, and git. I&#39;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 &#39;pull requests&#39; and I can see if what you value is being able to grab something from someone else - <i>i.e.</i> what Linus does daily (merge lots of peoples &#39;suggestions&#39;) 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 &#39;product.  For instance, I would like to be able to query, get me all the sources that make of the &#39;Intel Parallel Studio, Cluster Edition&#39;  (I don&#39;t think it can be done!!</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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 &#39;sccs get&#39; against every file and we could rebuild everything (VAX or PMAX) and it even included some of the &#39;layered products&#39; that the OS team controlled.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">So, my observation at Intel, is we have more people wasting backed time on &#39;maintaining our common pools&#39; here than we ever did at DEC or at any of start-ups.   As a sr person, I must say hmmmmm</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Anyway - that&#39;s my 2 cents.  </div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">** Although, I&#39;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.   <br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div></div>

  reply index

Thread overview: 85+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-09  6:25 [TUHS] PWB vs Unix/TS Warner Losh
2019-09-09  6:36 ` arnold
2019-09-10 15:16 ` Clem Cole
2019-09-11  0:28   ` Steve Johnson
2019-09-11  3:53   ` Warner Losh
2019-09-11 15:36     ` Clem Cole
2019-09-11 16:55       ` [TUHS] IBM Unix source licenses [was " Charles H Sauer
2019-09-12 19:31         ` Kevin Bowling
2019-09-12 20:59           ` Clem Cole
2019-09-12 21:09             ` [TUHS] IBM Unix source licenses - Series/1 NUXI Ronald Natalie
2019-09-12 21:31             ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Warner Losh
2019-09-12 22:30             ` jcs
2019-09-12 23:12               ` reed
2019-09-12 23:22                 ` jcs
2019-09-12 23:29               ` [TUHS] IBM Unix source licenses Warren Toomey
2019-09-13  7:06                 ` arnold
2019-09-13  8:30                 ` SPC
2019-09-14 18:29                   ` Warner Losh
2019-09-12 21:29           ` [TUHS] IBM Unix source licenses [was Re: PWB vs Unix/TS Charles H Sauer
2019-09-11 17:49       ` [TUHS] " Richard Salz
2019-09-11 17:52         ` ron
2019-09-11 21:44           ` Clem Cole
2019-09-11 18:11       ` Larry McVoy
2019-09-11 18:18         ` Richard Salz
2019-09-11 18:54           ` Larry McVoy
2019-09-11 21:05             ` Steve Johnson
2019-09-11 21:34             ` Steve Johnson
2019-09-11 21:57             ` Clem Cole
2019-09-11 22:50               ` Arthur Krewat
2019-09-11 21:59           ` Clem Cole
2019-09-11 21:50         ` Clem Cole
2019-09-11 22:49         ` Dave Horsfall
2019-09-12  3:43           ` [TUHS] SCCS Larry McVoy
2019-09-12  4:20             ` George Michaelson
2019-09-12  4:31               ` [TUHS] [SPAM] SCCS Larry McVoy
2019-09-12 13:44                 ` Tony Finch
2019-09-13  4:11                   ` Larry McVoy
2019-09-13  5:54                     ` Dave Horsfall
2019-09-13  8:00                       ` Peter Jeremy
2019-09-13 15:23                         ` Larry McVoy
2019-09-13 21:36                         ` Dave Horsfall
2019-09-12  4:28             ` [TUHS] SCCS Jon Forrest
2019-09-12  4:33               ` Larry McVoy
2019-09-12  6:12                 ` William Corcoran
2019-09-12 14:35                   ` Clem Cole [this message]
2019-09-13  5:22                 ` Dave Horsfall
2019-09-13  5:50                   ` Bakul Shah
2019-09-12 16:45               ` Eric Allman
2019-09-12 17:29                 ` Clem Cole
2019-09-12 17:47                   ` Warner Losh
2019-09-13  8:12                   ` emanuel stiebler
2019-09-13 21:11                     ` Steffen Nurpmeso
2019-09-13 21:17                       ` Larry McVoy
2019-09-13 21:48                         ` Bakul Shah
2019-09-13 23:12                           ` Steffen Nurpmeso
2019-09-13 23:03                         ` Steffen Nurpmeso
2019-09-14  1:55                           ` [TUHS] [SPAM] SCCS Larry McVoy
2019-09-16 17:23                             ` [TUHS] SCCS Steffen Nurpmeso
2019-09-16 20:31                               ` Larry McVoy
2019-09-17 17:57                                 ` Steffen Nurpmeso
2019-09-18  8:48                               ` Eric Allman
2019-09-18 17:33                                 ` Steffen Nurpmeso
2019-09-12 20:07             ` Nemo
2019-09-11 16:05   ` [TUHS] PWB vs Unix/TS Paul Winalski
2019-09-11 17:14     ` ron
2019-09-14  0:44   ` [TUHS] a book (was Re: PWB vs Unix/TS) reed
2019-09-14  2:53     ` Warner Losh
2019-09-15  2:18       ` Jon Steinhart
2019-09-15  2:39         ` Clem Cole
2019-09-15  3:24         ` Adam Thornton
2019-09-14 22:46     ` Clem cole
2019-09-15  0:58       ` Adam Thornton
2019-09-15  3:30         ` Eric Allman
2019-09-15  4:21           ` Larry McVoy
2019-09-15  5:17             ` Jon Steinhart
2019-09-15 20:14               ` Clem Cole
2019-09-15 20:21                 ` Jon Steinhart
2019-09-15 20:12           ` Clem Cole
2019-09-15 21:28             ` Dave Horsfall
2019-09-15 23:27               ` Clem cole
2019-09-15 23:45                 ` Richard Salz
2019-09-15  7:43     ` Andy Kosela
2019-09-12  4:25 [TUHS] SCCS Jon Steinhart
2019-09-13 21:37 Norman Wilson
2019-09-13 21:51 ` Larry McVoy

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAC20D2Pk2F-pb5_0kxT-5TNeZk--d27wHE_-AR09dXcPZbHyTA@mail.gmail.com \
    --to=clemc@ccc.com \
    --cc=lm@mcvoy.com \
    --cc=tuhs@minnie.tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

The Unix Heritage Society mailing list

Archives are clonable: git clone --mirror http://inbox.vuxu.org/tuhs

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.tuhs


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git