[TUHS] SCCS, TeamWare, BitKeeper, and Git

[TUHS] SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

As I mentioned in another post, I'm writing an invited paper for an
upcoming issue of IEEE Transactions on Software Engineering that will be a
50-year retrospective of my original 1975 SCCS paper (
mrochkind.com/aup/talks/SCCS-Slideshow.pdf). Can some people here review a
couple of paragraphs for accuracy?

*Decentralized Version Control (DVCS)*

*While VCSs like CVS and Subversion were centralized and had
pre-commit merging, a further advance was towards decentralization, with
post-commit merging. Probably the first DVCS was Sun WorkShop TeamWare,
created by Larry McVoy and announced in 1992 [sun]. It was implemented as a
layer on top of SCCS. McVoy later commercialized a successor system called
BitKeeper [Bitkeeper], which was layered on a re-implementation of SCCS,
which he called BitSCCS. TeamWare and BitKeeper took advantage of the
interleaved delta algorithm, also known as a weave, to implement an
efficient way to represent merged deltas by reference, instead of
reproducing code inside the repository. This is a lot more complicated to
do with reverse deltas, introduced by RCS.*

*In 2005 Linus Torvalds, creator of Linux [linux], invented the DVCS Git
[git] for Linux development, and since then Git has become widely used and
has supplanted BitKeeper.*

[more about DVCS follows]


I don't want to add more detail that would make these paragraphs any
longer, but I do want them to be accurate. Thanks!

Marc Rochkind

-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[G. Branden Robinson]

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

At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
> As I mentioned in another post, I'm writing an invited paper for an
> upcoming issue of IEEE Transactions on Software Engineering that will
> be a 50-year retrospective of my original 1975 SCCS paper (
> mrochkind.com/aup/talks/SCCS-Slideshow.pdf). Can some people here
> review a couple of paragraphs for accuracy?

I apologize for this not being quite responsive to your query, then.

1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
    popularizing, or perhaps _introducing_, the notion of decentralized
    version control to the dot-com era of hard-scrabble FLOSS developers
    who were building "Web 2.0" and whose startup employers, be they
    flush with cash or not, generally would not spring for a commercial
    VCS (which might not have been decentralized anyway).

    The most salient point here is that Linus Torvalds was not prescient
    or uniquely perceptive in recognizing the value of a DVCS.  Many
    people in the first half of the decade of the 2000s were chafing at
    the limitations of CVS in an increasingly networked environment, and
    Subversion was recognized as a conservative alternative even at the
    time.  This was conventional wisdom among engineers at my workplace.

    I urge us not to contribute to Torvalds's cult of celebrity as we
    did (and do) that of Bill Joy or Steve Jobs, suggesting that they
    had unique insights when they plainly didn't.  Sometimes a big name
    or reputation can lend some activation energy to an existing good
    idea (or persuade someone with a fat wallet to open it for financing
    of development), but it's important not to mistake what such
    celebrities should be credited with.  An example is how people
    mis-credit Bill Joy, solely, with developing curses.[1]

2.  "TeamWare and BitKeeper took advantage of the interleaved delta
    algorithm, also known as a weave, to implement an efficient way to
    represent merged deltas by reference, instead of reproducing code
    inside the repository. This is a lot more complicated to do with
    reverse deltas, introduced by RCS.*"

    I'd a like a second footnote directing me to where I can understand
    the mathematics supporting this claim.  Just out of nerd interest.

    Also, if one requires a shovel to bury Walter Tichy with, such a
    presentation would serve well...

Regards,
Branden

[1] See, e.g., the section "Relationship with vi":

    https://invisible-island.net/ncurses/ncurses.faq.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Larry McVoy]

On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
> At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
> > As I mentioned in another post, I'm writing an invited paper for an
> > upcoming issue of IEEE Transactions on Software Engineering that will
> > be a 50-year retrospective of my original 1975 SCCS paper (
> > mrochkind.com/aup/talks/SCCS-Slideshow.pdf). Can some people here
> > review a couple of paragraphs for accuracy?
> 
> I apologize for this not being quite responsive to your query, then.
> 
> 1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
>     popularizing, or perhaps _introducing_, the notion of decentralized
>     version control to the dot-com era of hard-scrabble FLOSS developers
>     who were building "Web 2.0" and whose startup employers, be they
>     flush with cash or not, generally would not spring for a commercial
>     VCS (which might not have been decentralized anyway).

BitKeeper was 3 years into development by then.  Here is the first BK
changeset:

ChangeSet@1.1, 1999-03-19 16:11:26-08:00, lm@lm.bitmover.com
  BitKeeper gets stored in BitKeeper.

>     The most salient point here is that Linus Torvalds was not prescient
>     or uniquely perceptive in recognizing the value of a DVCS.  

Couldn't agree more.  He, Dave Miller, and Richard Henderson came to my
house in SF because Dave was threatening to fork Linux because Linus
used no SCM at all.  That pushed all the merges to the next level, to
people like Dave.  It took me 4-5 hours of explaining how distributed
SCM would work for Linus to get it.  My wife was unimpressed with him.
Whatever, at the end of that day, he said "build that and I'll use it".
And we did, he did, and rate of development doubled (according to the
people who hated me) and was actually about 10x faster (according to the
people who could do math).

> 2.  "TeamWare and BitKeeper took advantage of the interleaved delta
>     algorithm, also known as a weave, to implement an efficient way to
>     represent merged deltas by reference, instead of reproducing code
>     inside the repository. This is a lot more complicated to do with
>     reverse deltas, introduced by RCS.*"
> 
>     I'd a like a second footnote directing me to where I can understand
>     the mathematics supporting this claim.  Just out of nerd interest.

See if this helps:

https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html

You can work out that SCCS/BK are doing what they claim by running 
bk annotate on a file that was authored by X but automerged by Y.
The authorship stays the same across the merge, that's not true in
most SCM systems that copy the data from the branch to the trunk.

Happy to answer any questions.  And, yes, git is a ginormous step
backwards.  Only one graph, BK had a graph per file so the GCA is
always the correct one, none of this try different ones until you
get one that automerges; since there is only one graph, all you 
get are commit comments, you lose the oh-so-valuable-file-comments
that you need when the crap hits the fan; you lose a boat load of
performance, especially in areas like annotate/blame when the repo
gets big, etc.  Git sucks, it really does.  Linus claims he wrote
it in a week and it shows.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

Thanks, Larry and Branden. I'll try to work what you're saying into my
paper.

Larry, I found your post of a few days ago (
https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html) very
illuminating, and I'd like to reference it, which I could do with that
post. But, is there some other, more referenceable article saying the same
thing that I can reference instead?

Regarding BK vs. Git. Even if BK is superior, can today's developers use
BK? My understanding is that it is no longer supported.

Is there a DVCS out there that's an alternative to Git?

The reason why this part of my paper has to be short is that I'm discussing
the influence of SCCS on software engineering, and its influence on DVCSs
is very indirect. My paper isn't a history of VCSs.

Marc

On Sat, Dec 14, 2024 at 11:53 AM Larry McVoy <lm@mcvoy.com> wrote:

> On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
> > At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
> > > As I mentioned in another post, I'm writing an invited paper for an
> > > upcoming issue of IEEE Transactions on Software Engineering that will
> > > be a 50-year retrospective of my original 1975 SCCS paper (
> > > mrochkind.com/aup/talks/SCCS-Slideshow.pdf). Can some people here
> > > review a couple of paragraphs for accuracy?
> >
> > I apologize for this not being quite responsive to your query, then.
> >
> > 1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
> >     popularizing, or perhaps _introducing_, the notion of decentralized
> >     version control to the dot-com era of hard-scrabble FLOSS developers
> >     who were building "Web 2.0" and whose startup employers, be they
> >     flush with cash or not, generally would not spring for a commercial
> >     VCS (which might not have been decentralized anyway).
>
> BitKeeper was 3 years into development by then.  Here is the first BK
> changeset:
>
> ChangeSet@1.1, 1999-03-19 16:11:26-08:00, lm@lm.bitmover.com
>   BitKeeper gets stored in BitKeeper.
>
> >     The most salient point here is that Linus Torvalds was not prescient
> >     or uniquely perceptive in recognizing the value of a DVCS.
>
> Couldn't agree more.  He, Dave Miller, and Richard Henderson came to my
> house in SF because Dave was threatening to fork Linux because Linus
> used no SCM at all.  That pushed all the merges to the next level, to
> people like Dave.  It took me 4-5 hours of explaining how distributed
> SCM would work for Linus to get it.  My wife was unimpressed with him.
> Whatever, at the end of that day, he said "build that and I'll use it".
> And we did, he did, and rate of development doubled (according to the
> people who hated me) and was actually about 10x faster (according to the
> people who could do math).
>
> > 2.  "TeamWare and BitKeeper took advantage of the interleaved delta
> >     algorithm, also known as a weave, to implement an efficient way to
> >     represent merged deltas by reference, instead of reproducing code
> >     inside the repository. This is a lot more complicated to do with
> >     reverse deltas, introduced by RCS.*"
> >
> >     I'd a like a second footnote directing me to where I can understand
> >     the mathematics supporting this claim.  Just out of nerd interest.
>
> See if this helps:
>
> https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html
>
> You can work out that SCCS/BK are doing what they claim by running
> bk annotate on a file that was authored by X but automerged by Y.
> The authorship stays the same across the merge, that's not true in
> most SCM systems that copy the data from the branch to the trunk.
>
> Happy to answer any questions.  And, yes, git is a ginormous step
> backwards.  Only one graph, BK had a graph per file so the GCA is
> always the correct one, none of this try different ones until you
> get one that automerges; since there is only one graph, all you
> get are commit comments, you lose the oh-so-valuable-file-comments
> that you need when the crap hits the fan; you lose a boat load of
> performance, especially in areas like annotate/blame when the repo
> gets big, etc.  Git sucks, it really does.  Linus claims he wrote
> it in a week and it shows.
> --
> ---
> Larry McVoy           Retired to fishing
> http://www.mcvoy.com/lm/boat
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Dan Cross]

On Sat, Dec 14, 2024 at 2:13 PM Marc Rochkind <mrochkind@gmail.com> wrote:
> [snip]
> Is there a DVCS out there that's an alternative to Git?
>[snip]

A few! Darcs, bazaar, mercurial are examples. Mercurial was fairly
popular 10 or 15 years ago, before git fully took over the mindshare.

A new VCS that a lot of folks are very excited about is Jujutsu:
https://github.com/martinvonz/jj. It's git compatible, and according
to their README uses git repositories as the "storage layer".

        - Dan C.

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Luther Johnson]

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

"Is there a DVCS out there that's an alternative to Git?"

I'm sure the list will offer many options, but I think you might want to
look into mentioning either Fossil or Mercurial as alternatives to Git.
I have used Mercurial a tiny bit, and I have used Fossil regularly over
the last several years. Considering commercial (not open source)
software, I think Perforce is another candidate, I have used it before,
not lately, but at the time I used it, I think it had a reasonably large
customer base.

On 12/14/2024 12:13 PM, Marc Rochkind wrote:
> Thanks, Larry and Branden. I'll try to work what you're saying into my
> paper.
>
> Larry, I found your post of a few days ago
> (https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html) very
> illuminating, and I'd like to reference it, which I could do with that
> post. But, is there some other, more referenceable article saying the
> same thing that I can reference instead?
>
> Regarding BK vs. Git. Even if BK is superior, can today's developers
> use BK? My understanding is that it is no longer supported.
>
> Is there a DVCS out there that's an alternative to Git?
>
> The reason why this part of my paper has to be short is that I'm
> discussing the influence of SCCS on software engineering, and its
> influence on DVCSs is very indirect. My paper isn't a history of VCSs.
>
> Marc
>
> On Sat, Dec 14, 2024 at 11:53 AM Larry McVoy <lm@mcvoy.com
> <mailto:lm@mcvoy.com>> wrote:
>
>     On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
>     > At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
>     > > As I mentioned in another post, I'm writing an invited paper
>     for an
>     > > upcoming issue of IEEE Transactions on Software Engineering
>     that will
>     > > be a 50-year retrospective of my original 1975 SCCS paper (
>     > > mrochkind.com/aup/talks/SCCS-Slideshow.pdf
>     <http://mrochkind.com/aup/talks/SCCS-Slideshow.pdf>). Can some
>     people here
>     > > review a couple of paragraphs for accuracy?
>     >
>     > I apologize for this not being quite responsive to your query, then.
>     >
>     > 1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
>     >     popularizing, or perhaps _introducing_, the notion of
>     decentralized
>     >     version control to the dot-com era of hard-scrabble FLOSS
>     developers
>     >     who were building "Web 2.0" and whose startup employers, be they
>     >     flush with cash or not, generally would not spring for a
>     commercial
>     >     VCS (which might not have been decentralized anyway).
>
>     BitKeeper was 3 years into development by then.  Here is the first BK
>     changeset:
>
>     ChangeSet@1.1, 1999-03-19 16:11:26-08:00, lm@lm.bitmover.com
>     <mailto:lm@lm.bitmover.com>
>       BitKeeper gets stored in BitKeeper.
>
>     >     The most salient point here is that Linus Torvalds was not
>     prescient
>     >     or uniquely perceptive in recognizing the value of a DVCS.
>
>     Couldn't agree more.  He, Dave Miller, and Richard Henderson came
>     to my
>     house in SF because Dave was threatening to fork Linux because Linus
>     used no SCM at all.  That pushed all the merges to the next level, to
>     people like Dave.  It took me 4-5 hours of explaining how distributed
>     SCM would work for Linus to get it.  My wife was unimpressed with him.
>     Whatever, at the end of that day, he said "build that and I'll use
>     it".
>     And we did, he did, and rate of development doubled (according to the
>     people who hated me) and was actually about 10x faster (according
>     to the
>     people who could do math).
>
>     > 2.  "TeamWare and BitKeeper took advantage of the interleaved delta
>     >     algorithm, also known as a weave, to implement an efficient
>     way to
>     >     represent merged deltas by reference, instead of reproducing
>     code
>     >     inside the repository. This is a lot more complicated to do with
>     >     reverse deltas, introduced by RCS.*"
>     >
>     >     I'd a like a second footnote directing me to where I can
>     understand
>     >     the mathematics supporting this claim.  Just out of nerd
>     interest.
>
>     See if this helps:
>
>     https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html
>
>     You can work out that SCCS/BK are doing what they claim by running
>     bk annotate on a file that was authored by X but automerged by Y.
>     The authorship stays the same across the merge, that's not true in
>     most SCM systems that copy the data from the branch to the trunk.
>
>     Happy to answer any questions.  And, yes, git is a ginormous step
>     backwards.  Only one graph, BK had a graph per file so the GCA is
>     always the correct one, none of this try different ones until you
>     get one that automerges; since there is only one graph, all you
>     get are commit comments, you lose the oh-so-valuable-file-comments
>     that you need when the crap hits the fan; you lose a boat load of
>     performance, especially in areas like annotate/blame when the repo
>     gets big, etc.  Git sucks, it really does.  Linus claims he wrote
>     it in a week and it shows.
>     --
>     ---
>     Larry McVoy           Retired to fishing http://www.mcvoy.com/lm/boat
>
>
>
> --
> /My new email address is mrochkind@gmail.com <mailto:mrochkind@gmail.com>/


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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[David Ryskalczyk]

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

I've seen a lot of discussion in recent days about Jujutsu. It's a standalone DVCS, but the primary production backend uses Git, making it significantly more practical to use than the other options.

https://github.com/martinvonz/jj

https://neugierig.org/software/blog/2024/12/jujutsu.html

https://ahal.ca/blog/2024/jujutsu-mercurial-haven/

David

> On Dec 14, 2024, at 3:54 PM, Luther Johnson <luther.johnson@makerlisp.com> wrote:
> 
> "Is there a DVCS out there that's an alternative to Git?"
> 
> I'm sure the list will offer many options, but I think you might want to look into mentioning either Fossil or Mercurial as alternatives to Git. I have used Mercurial a tiny bit, and I have used Fossil regularly over the last several years. Considering commercial (not open source) software, I think Perforce is another candidate, I have used it before, not lately, but at the time I used it, I think it had a reasonably large customer base.
> 
> On 12/14/2024 12:13 PM, Marc Rochkind wrote:
>> Thanks, Larry and Branden. I'll try to work what you're saying into my paper.
>> 
>> Larry, I found your post of a few days ago (https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html) very illuminating, and I'd like to reference it, which I could do with that post. But, is there some other, more referenceable article saying the same thing that I can reference instead?
>> 
>> Regarding BK vs. Git. Even if BK is superior, can today's developers use BK? My understanding is that it is no longer supported.
>> 
>> Is there a DVCS out there that's an alternative to Git?
>> 
>> The reason why this part of my paper has to be short is that I'm discussing the influence of SCCS on software engineering, and its influence on DVCSs is very indirect. My paper isn't a history of VCSs.
>> 
>> Marc
>> 
>> On Sat, Dec 14, 2024 at 11:53 AM Larry McVoy <lm@mcvoy.com <mailto:lm@mcvoy.com>> wrote:
>>> On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
>>> > At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
>>> > > As I mentioned in another post, I'm writing an invited paper for an
>>> > > upcoming issue of IEEE Transactions on Software Engineering that will
>>> > > be a 50-year retrospective of my original 1975 SCCS paper (
>>> > > mrochkind.com/aup/talks/SCCS-Slideshow.pdf <http://mrochkind.com/aup/talks/SCCS-Slideshow.pdf>). Can some people here
>>> > > review a couple of paragraphs for accuracy?
>>> > 
>>> > I apologize for this not being quite responsive to your query, then.
>>> > 
>>> > 1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
>>> >     popularizing, or perhaps _introducing_, the notion of decentralized
>>> >     version control to the dot-com era of hard-scrabble FLOSS developers
>>> >     who were building "Web 2.0" and whose startup employers, be they
>>> >     flush with cash or not, generally would not spring for a commercial
>>> >     VCS (which might not have been decentralized anyway).
>>> 
>>> BitKeeper was 3 years into development by then.  Here is the first BK
>>> changeset:
>>> 
>>> ChangeSet@1.1 <mailto:ChangeSet@1.1>, 1999-03-19 16:11:26-08:00, lm@lm.bitmover.com <mailto:lm@lm.bitmover.com>
>>>   BitKeeper gets stored in BitKeeper.
>>> 
>>> >     The most salient point here is that Linus Torvalds was not prescient
>>> >     or uniquely perceptive in recognizing the value of a DVCS.  
>>> 
>>> Couldn't agree more.  He, Dave Miller, and Richard Henderson came to my
>>> house in SF because Dave was threatening to fork Linux because Linus
>>> used no SCM at all.  That pushed all the merges to the next level, to
>>> people like Dave.  It took me 4-5 hours of explaining how distributed
>>> SCM would work for Linus to get it.  My wife was unimpressed with him.
>>> Whatever, at the end of that day, he said "build that and I'll use it".
>>> And we did, he did, and rate of development doubled (according to the
>>> people who hated me) and was actually about 10x faster (according to the
>>> people who could do math).
>>> 
>>> > 2.  "TeamWare and BitKeeper took advantage of the interleaved delta
>>> >     algorithm, also known as a weave, to implement an efficient way to
>>> >     represent merged deltas by reference, instead of reproducing code
>>> >     inside the repository. This is a lot more complicated to do with
>>> >     reverse deltas, introduced by RCS.*"
>>> > 
>>> >     I'd a like a second footnote directing me to where I can understand
>>> >     the mathematics supporting this claim.  Just out of nerd interest.
>>> 
>>> See if this helps:
>>> 
>>> https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html
>>> 
>>> You can work out that SCCS/BK are doing what they claim by running 
>>> bk annotate on a file that was authored by X but automerged by Y.
>>> The authorship stays the same across the merge, that's not true in
>>> most SCM systems that copy the data from the branch to the trunk.
>>> 
>>> Happy to answer any questions.  And, yes, git is a ginormous step
>>> backwards.  Only one graph, BK had a graph per file so the GCA is
>>> always the correct one, none of this try different ones until you
>>> get one that automerges; since there is only one graph, all you 
>>> get are commit comments, you lose the oh-so-valuable-file-comments
>>> that you need when the crap hits the fan; you lose a boat load of
>>> performance, especially in areas like annotate/blame when the repo
>>> gets big, etc.  Git sucks, it really does.  Linus claims he wrote
>>> it in a week and it shows.
>>> -- 
>>> ---
>>> Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat
>> 
>> 
>> 
>> --
>> My new email address is mrochkind@gmail.com <mailto:mrochkind@gmail.com>


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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Martin Schröder]

Am Sa., 14. Dez. 2024 um 20:14 Uhr schrieb Marc Rochkind <mrochkind@gmail.com>:
> Is there a DVCS out there that's an alternative to Git?

https://en.wikipedia.org/wiki/Comparison_of_version-control_software

might be a start. And of course needs updates.

Best
    Martin

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Greg A. Woods]

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

Hi Marc,

This is more of an aside, but as a long time and ongoing SCCS user I've
wondered about the vc(1) command included in the SCCS tool suite.

So I was hoping you (or anyone else reading) might be able to shed some
light on its origins and maybe give, or point to, some examples of how
it was intended to be used, or indeed how it ended up being used.

When I first encountered it, which would have been in the mid-1980s, I
thought it might be useful to help build a proper configuration
management system on top of or alongside SCCS, but I've never managed to
hack anything like that together myself, nor was I ever able to find any
examples of its use that might help me.

Most people I asked about vc(1) were dismissive and suggested it was
archaic and useless, or as with this time with a tangentially related
question where all I got was silence:

https://mirrors.nycbug.org/pub/The_Unix_Archive/Unix_Usenet/comp.unix.questions/1988-August/012896.html


--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Theodore Ts'o]

On Sat, Dec 14, 2024 at 03:03:30PM -0500, Dan Cross wrote:
> 
> A few! Darcs, bazaar, mercurial are examples. Mercurial was fairly
> popular 10 or 15 years ago, before git fully took over the mindshare.

There is no question that there are other DCVS's which are more
sophisticated than git.

But one could argue that there are other OS's which are more
"sophisticated", and that was their argument for why they were better
than Unix.  For example, I've had Multicians tell me about
super-sophistcated things which Unix or any more modern Unix
descendants *still* don't do, which they will claim is a reason why
Multics is "superior" to Unix.  But yet, there's no question that
Multics was a commercial failure, and that Unix's simplicity and ease
of porting to other architectures besides the DPS-8/M was one of the
reasons why Unix succeeded and Multics has been consigned to the
dustbin of history.

So I find it interesting how one the one hand, we will extol the
virtues of Unix's simplicity in terms of using byte streams for files,
as oposed to the horrendous record-based files used by Mainframes and
VMS, And yet we can *also* say that Git is stupid because it doesn't
track renames, while Bitkeeper does, and therefore it is better than
the simple blob-based model which is git.

One could make the argumet that "git was lucky; it was in the right
place at the right time, and managed to get mindshare", but I suspect
there are other people who might say the same thing about Unix and it
getting mindshare more out of luck than the fundametal superiority of
its technical architecture.

And I think there are many on this list who would contest mightily
that Unix was "just lucky".

Food for thought....

					- Ted

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Alexis]

"Theodore Ts'o" <tytso@mit.edu> writes:

> [T]here's no question that Multics was a commercial failure, and 
> that
> Unix's simplicity and ease of porting to other architectures 
> besides
> the DPS-8/M was one of the reasons why Unix succeeded and 
> Multics has
> been consigned to the dustbin of history.
>
> ...
>
> One could make the argumet that "git was lucky; it was in the 
> right
> place at the right time, and managed to get mindshare", but I 
> suspect
> there are other people who might say the same thing about Unix 
> and it
> getting mindshare more out of luck than the fundametal 
> superiority of
> its technical architecture.
>
> And I think there are many on this list who would contest 
> mightily
> that Unix was "just lucky".

Gabriel's "Worse Is Better" essay is coming irresistibly to mind 
.... i'd certainly be interested in this list's opinion of that 
piece, 30+ years later.


Alexis.

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Lars Brinkhoff]

Theodore Ts'o wrote:
> But yet, there's no question that Multics was a commercial failure

By which metric?  Honest question.  Multics seems to have been in
business around 1975-2000, but I don't know if it was in the read or in
the black.

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[sjenkin]

Greg,

I was never much of a developer, have written little code in last 25yrs,
more download, compile and use now :)

And in that light, used a number of VCS, open source & not, over the years.
Not a ‘power user’ :( 
but not unpracticed.

Reading the SCCS docs, ‘what’ and ‘vc’ seem related,
placing / looking for version related strings in code at a minimum.

‘what’ obviously is similar RCS’ ‘ident’, has its own SCCS id list.
I can’t think of an equivalent of ‘vc’ in RCS - doing something Configuration related.

I’ve done config management & conversion / port to new platforms on a few modest systems (1M lines of code)
and can see what you’re getting at with ‘vc’ and its ability to take any file, SCCS or not,
and rewrite them using AWK-like functionality.

There’s a nomenclature quirk problem in the man pages I had to get past:

	‘control character’ is used to mean the (ascii) delimiter for matched/substituted strings.
	With more a comms background, I first read it as low-value ASCII chars :)

I stumbled on Tony Finch’s blog, author of ‘unifdef’, and how he displays the version string in that program.

Inferences:

	- the people who wrote SCCS used ‘vc’, or people very close to them needed it, had it written for them.

	- it’s NOT trying to replicate Identifiers, as RCS ident does. This is quite different functionality.

	- ‘vc’ works on non-SCCS files, so it can work on make files, config, release & distribution scripts… 

	- the awk-like syntax, delimiter + keyword substitution suggests you’d not apply it to code - too easy to make a huge mess.

As you suggested, have a Configuration SCCS Repo storing all the components / version-id of all files for a Release to a set of target platforms,
and some scripts + ‘vc’ to reliably generate builds making bit-identical objects for a release.

First part of any good production acceptance test process would be ‘build it all from source’ - and check all created objects were bit-identical to Release Candidate.
I’ve heard people complain with ‘git’ that for some projects the compile time/date string is included - making invariant object builds impossible…
A retrograde step IMHO.

This would make sense if you were Bell Labs / USL around 1984 building source for many hardware targets, many O/S platforms.
They’d have automated the build/release process and (hopefully) insisted on bit-identical objects.

I’m not sure how many people understand Configuration Management - its subtle, even supporting two versions of the same system & tools.
I did enough to know I didn’t know much about it :)

cheers
steve

[ Notes at end ]

> On 15 Dec 2024, at 11:53, Greg A. Woods <woods@robohack.ca> wrote:
> 
> Hi Marc,
> 
> This is more of an aside, but as a long time and ongoing SCCS user I've
> wondered about the vc(1) command included in the SCCS tool suite.
> 
> So I was hoping you (or anyone else reading) might be able to shed some
> light on its origins and maybe give, or point to, some examples of how
> it was intended to be used, or indeed how it ended up being used.
> 
> When I first encountered it, which would have been in the mid-1980s, I
> thought it might be useful to help build a proper configuration
> management system on top of or alongside SCCS, but I've never managed to
> hack anything like that together myself, nor was I ever able to find any
> examples of its use that might help me.
> 
> Most people I asked about vc(1) were dismissive and suggested it was
> archaic and useless, or as with this time with a tangentially related
> question where all I got was silence:
> 
> https://mirrors.nycbug.org/pub/The_Unix_Archive/Unix_Usenet/comp.unix.questions/1988-August/012896.html
> 
> 
> --
> Greg A. Woods <gwoods@acm.org>
> 
> Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
> Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>


===============

Notes.

Inserting SCCS ID keywords in a file
	<http://courses.itee.uq.edu.au/csse2310/2012s1/resources/unixhelp/utilities1/sccs_insert.html>

3.2.1.2 Inserting SCCS ID Keywords
	<https://docs.oracle.com/cd/E19205-01/819-5262/aeucp/index.html>

ident
	<https://man.openbsd.org/ident.1>

AIX 4.3 what Command
	<https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/cmds/aixcmds6/what.htm>

AIX 4.3 List of Additional SCCS Commands
	<https://sites.ualberta.ca/dept/chemeng/AIX-43/share/man/info/C/a_doc_lib/aixprggd/genprogc/ls_sccs_cmds.htm>

	vc	Substitutes assigned values for identification keywords.

vc -- version control (SCCS)
	<http://osr507doc.sco.com/en/man/html.CP/vc.CP.html>
	The vc command is awk-like tool used for version control of sets of files. 
	While it is distributed as part of the SCCS package, it does not require the files it operates on to be under SCCS control.

===============

Tony Finch
2024-05-13 – Unix version control lore: what, ident
	<https://dotat.at/@/2024-05-13-what-ident.html>

[ on my mac ]

	[ both what & ident report no tags in /usr/bin/unifdef ]

	 steve$ unifdef -V 
	Version: unifdef-2.5.6.21f1388 
	FreeBSD: src/usr.bin/unifdef/unifdef.c,v 1.31 2011/01/21 18:10:11 fanf Exp 
	Author: Tony Finch (dot@dotat.at) 
	URL: http://dotat.at/prog/unifdef 

Each line is prefixed with an SCCS magic marker @(#) so that what can find it, and wrapped in an RCS-style $Keyword$so that ident can find it. 
There’s a fairly trivial version() function that spits out the copyright[] string when you run unifdef -V.

embedding versions from git

My projects have various horrible build scripts for embedding the version number from git. 
The basic idea is,
    • use an annotated or signed tag to mark a release, i.e. git tag -a or git tag -s
    • use git describe to get a version string that includes an extra number counting commits since the last release
    • maybe use git show --pretty=format:%ai -s HEAD to get a release date
    • stuff the outputs from git into the $Version$ and $Date$ RCS keywords

I enjoy keeping this old feature working, even though it isn’t very useful if no-one knows about it! 
Maybe if I blog about it, it’ll become more widespread?

===============
--
Steve Jenkin, IT Systems and Design 
0412 786 915 (+61 412 786 915)
PO Box 38, Kippax ACT 2615, AUSTRALIA

mailto:sjenkin@canb.auug.org.au http://members.tip.net.au/~sjenkin

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[sjenkin]

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

Apologies for SPAMing the list - was meant to be a personal note to Greg.

My mail program bested me :(

> On 15 Dec 2024, at 19:16, sjenkin@canb.auug.org.au wrote:
> 
> Greg,
> 
> I was never much of a developer, have written little code in last 25yrs,
> more download, compile and use now :)
> 

--

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[G. Branden Robinson]

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

[replying to Marc's message because Larry's is not in my inbox]

At 2024-12-14T12:13:40-0700, Marc Rochkind wrote:
> On Sat, Dec 14, 2024 at 11:53 AM Larry McVoy <lm@mcvoy.com> wrote:
> > On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
> > > At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
> > > 1.  Tom Lord's Arch (ca. 2001) was at one timely recognized for
> > > popularizing, or perhaps _introducing_, the notion of
> > > decentralized version control to the dot-com era of hard-scrabble
> > > FLOSS developers who were building "Web 2.0" and whose startup
> > > employers, be they flush with cash or not, generally would not
> > > spring for a commercial VCS (which might not have been
> > > decentralized anyway).
> >
> > BitKeeper was 3 years into development by then.

I get that you're attentive to the matter of priority here, but I wrote
my paragraph carefully--although I see not quite carefully enough.

Arch popularized or introduced the notion of decentralized version
control to hard-scrabble FLOSS developers in the dot-com era whose
employers would not spend money on a commercial VCS.  I recollect now
that BK was available under a free-to-use license--as long as one didn't
get too curious, like Andrew Tridgell, or wish to remain at liberty to
participate in FLOSS projects that were themselves VCSes.  Such a
restriction was unacceptable to engineers in my circle (Debian people,
and Debian-adjacent people through my workplace).

From our perspective, BitKeeper was about as affordable and as appealing
as ClearCase.

And at my workplace, management wasn't interested in paying money to
cram down a VCS that the engineers would grumble about using.  We
muddled through, mostly with Subversion, as I recall.  We didn't have to
face the scale of coordination challenge that the Linux kernel did.

> > > 2.  "TeamWare and BitKeeper took advantage of the interleaved
> > >     delta algorithm, also known as a weave, to implement an
> > >     efficient way to represent merged deltas by reference, instead
> > >     of reproducing code inside the repository. This is a lot more
> > >     complicated to do with reverse deltas, introduced by RCS.*"
> > >
> > >     I'd a like a second footnote directing me to where I can
> > >     understand the mathematics supporting this claim.  Just out of
> > >     nerd interest.
> >
> > See if this helps:
> >
> > https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html

I saw that, and it sheds some light, but it doesn't rise to the level of
a theorem.

If I were a mathematician, I might know what analytical discipline to
bring to bear on my question to you, but the best I can do is to mumble
about how it looks like you need both graph theory and set theory for
this.  And I lack the category theory or other means to understand
whether and how those two might compose.  And I don't know that category
theory would even help; it simply seems to be the device most often
employed to, uh, uncover higher-level isomorphisms in problem domains.

(That's where I duck a tomato hurled from the audience.)

A good mathematical expositor could, I add, employ these tools without
leaning too hard on the formalisms, and produce a writeup that is
broadly accessible.

We used to have USENIX for this sort of thing...

> > You can work out that SCCS/BK are doing what they claim by running
> > bk annotate on a file that was authored by X but automerged by Y.
> > The authorship stays the same across the merge, that's not true in
> > most SCM systems that copy the data from the branch to the trunk.

I dimly recall that the "merge problem" was one of the shoals upon which
Subversion, if not quite ran aground upon, found itself adjacently
becalmed.

> > Happy to answer any questions.

I've noted your enthusiasm for the weave and BK's amplification of the
concept.  What I think you need is, as noted, a mathematical expositor
who can express the novelty of Rochkind's and your contributions in
terms that professionals who have little contact with the problems of
"source code configuration management" (an alternative nomenclature for
"version control" I've encountered) can comprehend.  You've tried
popularizing to the masses.  My conclusion is that, at best, they stare
slackly at you and say, "Git does that.  I use Git.".  To get your
innovation more broadly recognized, you may therefore have to take your
case to the ivory tower.

Despite the university training that many (most?) software engineers
receive, and the many tools that other engineering disciplines and
applied mathematics have to offer our field, there is little cross-
pollination.  Relatively few programmers actually read Dijkstra or
Hoare.  You're doing well if you can get them to read Brooks.  Too
often, in my view, the only value "theoretical computer science"[1] has
is as a fountainhead of buzzwords one can spray on a slide deck for
one's manager to pitch to a promotion committee.  I had to go to work at
a research lab to find an environment where people comfortably moved
back and forth between these domains.  Naturally, its budget got
savaged.  The grandparent organization wanted "an AI story".

Regards,
Branden

[1] I strongly dislike that term because of what it implies when the
    modifier is deleted: if you have a science without a theoretical
    framework, what you have is not a science.  I suspect it is
    preferred by math-phobes and managers who won't look past an
    impending deadline.  ("Who cares if it won't scale?  That's a
    problem for NEXT quarter.  Get it into production.")

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[G. Branden Robinson]

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

At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
> Theodore Ts'o wrote:
> > But yet, there's no question that Multics was a commercial failure
> 
> By which metric?  Honest question.  Multics seems to have been in
> business around 1975-2000, but I don't know if it was in the read or
> in the black.

I note that that's longer than MS-DOS was a commercial product.

People seem mighty quick to use words like "irrelevant" or "failure" as
a substitute for reasoned argument.

Maybe I would, in fact, hate using Multics.  But I can't forget that
well after Unix had fledged, its developers at CSRC found it necessary
and/or desirable to borrow back a Multics concept: they named it mmap().

Not having been concieved as desirable from the start, it was grafted
on, with negative consequences.  The archives of this list feature
multiple war stories from Larry McVoy about how, as I recollect,
unifying the buffer cache was a dragon that bedeviled every version of
Unix until SunOS 4 finally slayed it.  (Have I got that right?)

And promptly got chucked overboard for a System V kernel because that's
how glorious the software industry is.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Rob Pike]

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

Google ran on Perforce in the early days, then on an internal
reimplementation that could scale better (long story). I believe that's
still the case, as git continues to be desired by the users but unworkable
as the core repo at the required scale. Clever hackery allows git to feel
like it's being used, but it's all above what was at least at one time
Perforce.

My info could well be out of date, though.

-rob


On Sun, Dec 15, 2024 at 8:44 PM G. Branden Robinson <
g.branden.robinson@gmail.com> wrote:

> At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
> > Theodore Ts'o wrote:
> > > But yet, there's no question that Multics was a commercial failure
> >
> > By which metric?  Honest question.  Multics seems to have been in
> > business around 1975-2000, but I don't know if it was in the read or
> > in the black.
>
> I note that that's longer than MS-DOS was a commercial product.
>
> People seem mighty quick to use words like "irrelevant" or "failure" as
> a substitute for reasoned argument.
>
> Maybe I would, in fact, hate using Multics.  But I can't forget that
> well after Unix had fledged, its developers at CSRC found it necessary
> and/or desirable to borrow back a Multics concept: they named it mmap().
>
> Not having been concieved as desirable from the start, it was grafted
> on, with negative consequences.  The archives of this list feature
> multiple war stories from Larry McVoy about how, as I recollect,
> unifying the buffer cache was a dragon that bedeviled every version of
> Unix until SunOS 4 finally slayed it.  (Have I got that right?)
>
> And promptly got chucked overboard for a System V kernel because that's
> how glorious the software industry is.
>
> Regards,
> Branden
>

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Lars Brinkhoff]

G. Branden Robinson wrote:
> well after Unix had fledged, its developers at CSRC found it necessary
> and/or desirable to borrow back a Multics concept: they named it mmap().

It has been argued the borrowing was from TENEX.  TENEX in turn would
have been influenced by Multics and the SDS 940 timesharing system.

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Larry McVoy]

On Sun, Dec 15, 2024 at 03:34:47AM -0600, G. Branden Robinson wrote:
> > > > 2.  "TeamWare and BitKeeper took advantage of the interleaved
> > > >     delta algorithm, also known as a weave, to implement an
> > > >     efficient way to represent merged deltas by reference, instead
> > > >     of reproducing code inside the repository. This is a lot more
> > > >     complicated to do with reverse deltas, introduced by RCS.*"
> > > >
> > > >     I'd a like a second footnote directing me to where I can
> > > >     understand the mathematics supporting this claim.  Just out of
> > > >     nerd interest.
> > >
> > > See if this helps:
> > >
> > > https://www.tuhs.org/pipermail/tuhs/2024-December/031188.html
> 
> I saw that, and it sheds some light, but it doesn't rise to the level of
> a theorem.

Try rereading it a few times.  And work through the various versions of
the history file I wrote out.  Everything you need to understand is right
there.  I get that it isn't easy, but it isn't that hard either.

> If I were a mathematician, I might know what analytical discipline to
> bring to bear on my question to you, but the best I can do is to mumble
> about how it looks like you need both graph theory and set theory for
> this.  

You need to be able to visualize a graph, yes.  And Rick would agree you
need some education to _really_ understand everything.  I'd argue you need
very little to get the basics.

Remember, the claim is that an automerge is a set thing only, no changes
to the weave.  I demonstrated that.

> A good mathematical expositor could, I add, employ these tools without
> leaning too hard on the formalisms, and produce a writeup that is
> broadly accessible.
> 
> We used to have USENIX for this sort of thing...

Indeed.  And if USENIX were still a thing, I might write that paper.  I'm
not particularly motivated.  I participated in a 3 day SCM something a
while back, put on by google and facebook.  I spent 3 days listening to
their problems, and on most of them, I said "yeah, we solved that, here
is what we did".  And then watched while they ignored everything.

So I'm not hopeful that people will get it.  If I were younger, I might
write the paper anyway but I'm not.  I tried, BK is open source, you can
go read the code (I know of one guy who did and came back claiming it was
the most pleasant C source base he had ever seen, but that's it.  Noone
else has said boo).

> I've noted your enthusiasm for the weave and BK's amplification of the
> concept.  What I think you need is, as noted, a mathematical expositor
> who can express the novelty of Rochkind's and your contributions in
> terms that professionals who have little contact with the problems of
> "source code configuration management" (an alternative nomenclature for
> "version control" I've encountered) can comprehend.  You've tried
> popularizing to the masses.  My conclusion is that, at best, they stare
> slackly at you and say, "Git does that.  I use Git.".  To get your
> innovation more broadly recognized, you may therefore have to take your
> case to the ivory tower.

You're almost there.  What they say is "I use Github".  Github has
dumbed down DVCS to the point they aren't much different than CVS.
When I realized that years ago, I retired.  My belief is BK is sort of
like betamax, it's better but VHS won.  It is what it is.

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Bakul Shah via TUHS]

On Dec 15, 2024, at 6:31 AM, Larry McVoy <lm@mcvoy.com> wrote:
> 
> Indeed.  And if USENIX were still a thing, I might write that paper.  I'm
> not particularly motivated.  I participated in a 3 day SCM something a
> while back, put on by google and facebook.  I spent 3 days listening to
> their problems, and on most of them, I said "yeah, we solved that, here
> is what we did".  And then watched while they ignored everything.
> 
> So I'm not hopeful that people will get it.  If I were younger, I might
> write the paper anyway but I'm not.

A well written paper (as opposed to random discussions in a
meeting with multiple interruptions) would definitely help
people get it. I certainly would read it, in preference to
127K+ LoC in bitkeeper/src!

>> I've noted your enthusiasm for the weave and BK's amplification of the
>> concept.  What I think you need is, as noted, a mathematical expositor
>> who can express the novelty of Rochkind's and your contributions in
>> terms that professionals who have little contact with the problems of
>> "source code configuration management" (an alternative nomenclature for
>> "version control" I've encountered) can comprehend.  You've tried
>> popularizing to the masses.  My conclusion is that, at best, they stare
>> slackly at you and say, "Git does that.  I use Git.".  To get your
>> innovation more broadly recognized, you may therefore have to take your
>> case to the ivory tower.
> 
> You're almost there.  What they say is "I use Github".  Github has
> dumbed down DVCS to the point they aren't much different than CVS.
> When I realized that years ago, I retired.  My belief is BK is sort of
> like betamax, it's better but VHS won.  It is what it is.

Purely as a thought experiment & with the benefit of hindsight:
What would you do differently if you were to reimplement bk?
What were some things you wanted to do but didn't get around to?
Include any blue sky ideas! Include any simplifying ideas!

Given that there are newer than git efforts like jujitsu and pijul
etc., git won't be the last word. Though it hasn't reached the VHS
stage of obsolescence!

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

On Sat, Dec 14, 2024 at 6:43 PM Greg A. Woods <woods@robohack.ca> wrote:

> Hi Marc,
>
> This is more of an aside, but as a long time and ongoing SCCS user I've
> wondered about the vc(1) command included in the SCCS tool suite.
>
> So I was hoping you (or anyone else reading) might be able to shed some
> light on its origins and maybe give, or point to, some examples of how
> it was intended to be used, or indeed how it ended up being used.
>

I had completely forgotten about the vc command until I read this post. Vc
was a language-independent macro processor mostly concerned with excluding
or including lines of text based on the evaluation of logical expressions.

Even though "vc" stands for "version control," it has nothing to do with
version control as that phrase is used nowadays. In the early 1970s where I
worked at Bell Labs, we (or at least I) used the term "release" to refer to
the different forms of a file as development proceeded, and "version" to
refer to ongoing variants of the file. For example, there might be a
version of some program for Southwestern Bell and a different version for
New York Telephone. Those two versions were contained in the same identical
sets of source files.

I just looked again at my 1975 paper and I don't think the word "version"
appears anywhere. The terms "release" and "level" appear.

I designed vc, but it was implemented by a college student who was with us
for the Summer. I credit a woman named Sabrina Feczko in my paper, and I
think it was her. As I mentioned, vc was totally standalone so Sabrina
didn't have to concern herself with all the squirrely code in the main part
of SCCS.

Vc disappeared at some point. I don't think it was ever used, as it was
intended for mainframe programs that were being developed (but not
compiled) on PWB/UNIX. For UNIX development, C had its own macro processor.

Incidentally, UNIX had a different language-independent macro processor
called m6. I think it was created by Doug McIlroy and Andy Hall, and, as I
recall, that was even before UNIX became widely used. Hall's M6
implementation was in Fortran, possibly initially for the GE/Honeywell
machines running at Murray Hill. Even before I'd heard of UNIX and before I
did SCCS, I got the source from Andy and compiled M6 on our IBM mainframe.
I'm sure Doug can provide a lot more information about M6. I recall once
talking to Andy about a minor bug, and he said that he knew about it, had
talked to Doug about it, and Doug said let it go. (I was just starting out
at Holmdel and had never met Doug, Andy, or anybody else at Murray Hill. I
didn't know it, but Ken and Dennis were writing the first version of UNIX
around that time.)

Marc

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind@gmail.com> wrote:

>
> Incidentally, UNIX had a different language-independent macro processor
> called m6. I think it was created by Doug McIlroy and Andy Hall, and, as I
> recall, that was even before UNIX became widely used. Hall's M6
> implementation was in Fortran, possibly initially for the GE/Honeywell
> machines running at Murray Hill. Even before I'd heard of UNIX and before I
> did SCCS, I got the source from Andy and compiled M6 on our IBM mainframe.
> I'm sure Doug can provide a lot more information about M6. I recall once
> talking to Andy about a minor bug, and he said that he knew about it, had
> talked to Doug about it, and Doug said let it go. (I was just starting out
> at Holmdel and had never met Doug, Andy, or anybody else at Murray Hill. I
> didn't know it, but Ken and Dennis were writing the first version of UNIX
> around that time.)
>

Correction: The version of M6 for UNIX was called M4. Maybe because it was
only 2/3 as complete?

*Doug?*

Marc

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Larry McVoy]

On Sun, Dec 15, 2024 at 08:33:13AM -0800, Bakul Shah wrote:
> Purely as a thought experiment & with the benefit of hindsight:
> What would you do differently if you were to reimplement bk?
> What were some things you wanted to do but didn't get around to?
> Include any blue sky ideas! Include any simplifying ideas!

I'd finish nested repositories.  We got them mostly right but we never
finished support for renaming a sub repository (what git calls submodules).
By "right" I mean you couldn't really tell the difference between a
single giant repository and a nested collection of repositories.

I'd try to come up with some sort of named branches support.  We had
a design but never got to it.  It's pretty limiting in BK that the
only way to have branches is in a bunch of clones.  If your repo is
big enough, the time/space to rebuild things can get to be too much.

As part of the named branches work, we came up with a model that would
let you have a DAG but have straight line history as the visible part,
you can increase verbosity to get back to the full DAG if you want.
The idea was to have "integration trees" where the straight line 
history is the tip of each push.  Lots of people use git rebase to
get straight line history and I hate it.  You lose lots of useful
information but apparently I'm the only guy who cares.

> Given that there are newer than git efforts like jujitsu and pijul
> etc., git won't be the last word. Though it hasn't reached the VHS
> stage of obsolescence!

The problem is they are still using git under the covers.  That's just
a painful step backwards in my mind.
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[arnold]

> Correction: The version of M6 for UNIX was called M4. Maybe because it was
> only 2/3 as complete?

IIRC the V6 manual mentions m6, and m4 shows up in V7. But it may
have been v5 -> v6 where that happened.

If m6 was Fortran and m4 C, then that would (sort of) explain the change.

> *Doug?*

Yes, exactly, Doug?

Thanks,

Arnold

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Chet Ramey via TUHS]

[-- Attachment #1.1: Type: text/plain, Size: 883 bytes --]

On 12/15/24 4:43 AM, G. Branden Robinson wrote:
> At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:

> Maybe I would, in fact, hate using Multics.  But I can't forget that
> well after Unix had fledged, its developers at CSRC found it necessary
> and/or desirable to borrow back a Multics concept: they named it mmap().

I think it was primarily inspired by TENEX/TOPS-20, and it was the CSRG
who proposed it. The concepts are described in CSRG TR/4 and mmap()
ended up described in the 4.2BSD manual, but not implemented.

I don't think Reiser's VM system at the Labs included mmap(), but I think
it did have something similar. Of course, that never really saw the light
of day.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Luther Johnson]

I don't know where mmap showed up in vanilla BSD distributions, but it
was in SunOS 4.0, I used it. To the other points, the Multics
"one-level-store" idea was very powerful, and was an important influence
in Apollo Domain/OS, and it was probably there in Prime Computer's OS too.

On 12/15/2024 12:02 PM, Chet Ramey via TUHS wrote:
> On 12/15/24 4:43 AM, G. Branden Robinson wrote:
>> At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
>
>> Maybe I would, in fact, hate using Multics.  But I can't forget that
>> well after Unix had fledged, its developers at CSRC found it necessary
>> and/or desirable to borrow back a Multics concept: they named it mmap().
>
> I think it was primarily inspired by TENEX/TOPS-20, and it was the CSRG
> who proposed it. The concepts are described in CSRG TR/4 and mmap()
> ended up described in the 4.2BSD manual, but not implemented.
>
> I don't think Reiser's VM system at the Labs included mmap(), but I think
> it did have something similar. Of course, that never really saw the light
> of day.
>

[TUHS] Re: M<some number> macros, wasRe: SCCS

[John Levine]

>On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind@gmail.com> wrote:
>> Incidentally, UNIX had a different language-independent macro processor
>> called m6. ...

>Correction: The version of M6 for UNIX was called M4. Maybe because it was
>only 2/3 as complete?

The Wikipedia article on macroprocessors says that M6 was written in
the 1960s by McIlroy, Morris, and Hall, based on GPM and Trac, written
in Fortran and ported to v2 Unix.

M4 was written in the 1970s by Kernighan and Ritchie in C and is still
around, notably as impenetrable magic in GNU autoconfig and sendmail
config files. It looks a lot like GPM.

As an old Trac user I'd be interested to hear what M6 was like. The
Wikipedia article has a footnote pointing to a book by A J Cole, but I
found a copy of the book and it says nothing about M6 and has only a
passing reference to McIlroy.

R's,
John

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[John Levine]

It appears that Lars Brinkhoff <lars@nocrew.org> said:
>G. Branden Robinson wrote:
>> well after Unix had fledged, its developers at CSRC found it necessary
>> and/or desirable to borrow back a Multics concept: they named it mmap().
>
>It has been argued the borrowing was from TENEX.  TENEX in turn would
>have been influenced by Multics and the SDS 940 timesharing system.

mmap() is a lot more like Tenex than it is like Multics.  Tenex ran
on a PDP-10 with a flat 18 bit address space, and you could map files
to places in that address space.  It didn't have any of the Multics
segment stuff where a process was a collection of segments and you
made a segment addressable which implicitly mapped the whole segment.

[TUHS] Re: M<some number> macros, wasRe: SCCS

[G. Branden Robinson]

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

At 2024-12-15T15:09:20-0500, John Levine wrote:
> >On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind@gmail.com> wrote:
> >> Incidentally, UNIX had a different language-independent macro processor
> >> called m6. ...
> 
> >Correction: The version of M6 for UNIX was called M4. Maybe because it was
> >only 2/3 as complete?
> 
> The Wikipedia article on macroprocessors says that M6 was written in
> the 1960s by McIlroy, Morris, and Hall, based on GPM and Trac, written
> in Fortran and ported to v2 Unix.
> 
> M4 was written in the 1970s by Kernighan and Ritchie in C and is still
> around, notably as impenetrable magic in GNU autoconfig and sendmail
> config files. It looks a lot like GPM.

Being aware of its reputation, I had some trepidation about using it,
and found its impenetrability to be overstated.

For a few years now I've used it to generate two man pages from a single
source: groff_man(7) and groff_man_style(7).

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in?h=1.23.0

The only thing I stubbed my toe on is m4's appropriation of common
English words for its command language.  A prefix sigil before such
words would have been a better choice.  But I got around that, too.

https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n252

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Dan Cross]

On Sun, Dec 15, 2024 at 2:12 PM Luther Johnson
<luther.johnson@makerlisp.com> wrote:
> I don't know where mmap showed up in vanilla BSD distributions, but it
> was in SunOS 4.0, I used it.

kern_mman.c shows up in 4.1c, but is behind an #ifdef; I gather it
wasn't fully implemented. It was described in 4.2, as mentioned, but
wasn't "fully functional" until Net/2 (according to mmap(2), anyway).

Sun's version was an independent implementation.

As mentioned by Chet, the interface is modeled after the PMAP call on
TENEX/TOPS-20. The virtual memory system on TENEX, in turn, was at
least partially influenced by Multics, so there is some Multics
intellectual DNA (perhaps mutated :-)) in mmap(), though it's
indirect.

        - Dan C.

> To the other points, the Multics
> "one-level-store" idea was very powerful, and was an important influence
> in Apollo Domain/OS, and it was probably there in Prime Computer's OS too.
>
> On 12/15/2024 12:02 PM, Chet Ramey via TUHS wrote:
> > On 12/15/24 4:43 AM, G. Branden Robinson wrote:
> >> At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
> >
> >> Maybe I would, in fact, hate using Multics.  But I can't forget that
> >> well after Unix had fledged, its developers at CSRC found it necessary
> >> and/or desirable to borrow back a Multics concept: they named it mmap().
> >
> > I think it was primarily inspired by TENEX/TOPS-20, and it was the CSRG
> > who proposed it. The concepts are described in CSRG TR/4 and mmap()
> > ended up described in the 4.2BSD manual, but not implemented.
> >
> > I don't think Reiser's VM system at the Labs included mmap(), but I think
> > it did have something similar. Of course, that never really saw the light
> > of day.
> >
>

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Tom Lyon]

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

Yeah, the big changes in SunOS 4.0 were all around mmap and shared
libraries.

But I did a tiny subset of mmap - for mapping device registers only - in
SunOS 2 (or 3?).  But I used the CSRG spec for mmap.

On Sun, Dec 15, 2024 at 12:25 PM Dan Cross <crossd@gmail.com> wrote:

> On Sun, Dec 15, 2024 at 2:12 PM Luther Johnson
> <luther.johnson@makerlisp.com> wrote:
> > I don't know where mmap showed up in vanilla BSD distributions, but it
> > was in SunOS 4.0, I used it.
>
> kern_mman.c shows up in 4.1c, but is behind an #ifdef; I gather it
> wasn't fully implemented. It was described in 4.2, as mentioned, but
> wasn't "fully functional" until Net/2 (according to mmap(2), anyway).
>
> Sun's version was an independent implementation.
>
> As mentioned by Chet, the interface is modeled after the PMAP call on
> TENEX/TOPS-20. The virtual memory system on TENEX, in turn, was at
> least partially influenced by Multics, so there is some Multics
> intellectual DNA (perhaps mutated :-)) in mmap(), though it's
> indirect.
>
>         - Dan C.
>
> > To the other points, the Multics
> > "one-level-store" idea was very powerful, and was an important influence
> > in Apollo Domain/OS, and it was probably there in Prime Computer's OS
> too.
> >
> > On 12/15/2024 12:02 PM, Chet Ramey via TUHS wrote:
> > > On 12/15/24 4:43 AM, G. Branden Robinson wrote:
> > >> At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
> > >
> > >> Maybe I would, in fact, hate using Multics.  But I can't forget that
> > >> well after Unix had fledged, its developers at CSRC found it necessary
> > >> and/or desirable to borrow back a Multics concept: they named it
> mmap().
> > >
> > > I think it was primarily inspired by TENEX/TOPS-20, and it was the CSRG
> > > who proposed it. The concepts are described in CSRG TR/4 and mmap()
> > > ended up described in the 4.2BSD manual, but not implemented.
> > >
> > > I don't think Reiser's VM system at the Labs included mmap(), but I
> think
> > > it did have something similar. Of course, that never really saw the
> light
> > > of day.
> > >
> >
>

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

[TUHS] Re: M<some number> macros, wasRe: SCCS

[Charles H Sauer (he/him)]

On 12/15/2024 2:17 PM, G. Branden Robinson wrote:
> At 2024-12-15T15:09:20-0500, John Levine wrote:
>>> On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind@gmail.com> wrote:
>>>> Incidentally, UNIX had a different language-independent macro processor
>>>> called m6. ...
>>
>>> Correction: The version of M6 for UNIX was called M4. Maybe because it was
>>> only 2/3 as complete?
>>
>> The Wikipedia article on macroprocessors says that M6 was written in
>> the 1960s by McIlroy, Morris, and Hall, based on GPM and Trac, written
>> in Fortran and ported to v2 Unix.
>>
>> M4 was written in the 1970s by Kernighan and Ritchie in C and is still
>> around, notably as impenetrable magic in GNU autoconfig and sendmail
>> config files. It looks a lot like GPM.
> 
> Being aware of its reputation, I had some trepidation about using it,
> and found its impenetrability to be overstated.
> 
> For a few years now I've used it to generate two man pages from a single
> source: groff_man(7) and groff_man_style(7).
> 
> https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in?h=1.23.0
> 
> The only thing I stubbed my toe on is m4's appropriation of common
> English words for its command language.  A prefix sigil before such
> words would have been a better choice.  But I got around that, too.
> 
> https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n252
> 
> Regards,
> Branden

In 1997, when CSS was just beginning, long before 
https://en.wikipedia.org/wiki/M4_%28computer_language%29 was started in 
2004, and subsequently illustrated m4 macros for creating HTML, I 
started using m4 macros extensively to define Web pages in such a matter 
that they could mimic appearance of other pages, and taught others at 
our startup to use those macros, so that our customers could use our 
software while retaining appearance consistent with the rest of their 
pages. Another way to think of the macros is that they comprise a static 
content management system – the content is stored in m4 files, which are 
transformed into HTML in advance, vs. more dynamic page generation in a 
typical content management system.
https://web.archive.org/web/19990125090055/http://hire.com/ describes 
the software. 
https://web.archive.org/web/19980209192647/http://www.eds.com/careers/overview/cr_overview.shtml, 
https://web.archive.org/web/19990224005553/http://world4.hire.com/SVB/, and
https://web.archive.org/web/19990422144616/http://www.careerstop.org/job.htm 
show remnants of customer pages created with those m4 macros.

More at 
https://technologists.com/notes/2007/11/02/css-a-mans-got-to-know-his-limitations-2/


Charlie


-- 
voice: +1.512.784.7526       e-mail: sauer@technologists.com
fax: +1.512.346.5240         Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer

[TUHS] Re: M<some number> macros, wasRe: SCCS

[Marc Rochkind]

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

I found this TUHS thread from 2019:

https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/thread/GPFOZNHNX2JOPPTPJEPRILDIT5O7N6QS/

in which Andy Hall's 1972 memo on M6 is referenced:

https://plan9.io/cm/cs/cstr/2.pdf

Marc

On Sun, Dec 15, 2024 at 2:53 PM Charles H Sauer (he/him) <
sauer@technologists.com> wrote:

> On 12/15/2024 2:17 PM, G. Branden Robinson wrote:
> > At 2024-12-15T15:09:20-0500, John Levine wrote:
> >>> On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind@gmail.com>
> wrote:
> >>>> Incidentally, UNIX had a different language-independent macro
> processor
> >>>> called m6. ...
> >>
> >>> Correction: The version of M6 for UNIX was called M4. Maybe because it
> was
> >>> only 2/3 as complete?
> >>
> >> The Wikipedia article on macroprocessors says that M6 was written in
> >> the 1960s by McIlroy, Morris, and Hall, based on GPM and Trac, written
> >> in Fortran and ported to v2 Unix.
> >>
> >> M4 was written in the 1970s by Kernighan and Ritchie in C and is still
> >> around, notably as impenetrable magic in GNU autoconfig and sendmail
> >> config files. It looks a lot like GPM.
> >
> > Being aware of its reputation, I had some trepidation about using it,
> > and found its impenetrability to be overstated.
> >
> > For a few years now I've used it to generate two man pages from a single
> > source: groff_man(7) and groff_man_style(7).
> >
> >
> https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/groff_man.7.man.in?h=1.23.0
> >
> > The only thing I stubbed my toe on is m4's appropriation of common
> > English words for its command language.  A prefix sigil before such
> > words would have been a better choice.  But I got around that, too.
> >
> >
> https://git.savannah.gnu.org/cgit/groff.git/tree/tmac/tmac.am?h=1.23.0#n252
> >
> > Regards,
> > Branden
>
> In 1997, when CSS was just beginning, long before
> https://en.wikipedia.org/wiki/M4_%28computer_language%29 was started in
> 2004, and subsequently illustrated m4 macros for creating HTML, I
> started using m4 macros extensively to define Web pages in such a matter
> that they could mimic appearance of other pages, and taught others at
> our startup to use those macros, so that our customers could use our
> software while retaining appearance consistent with the rest of their
> pages. Another way to think of the macros is that they comprise a static
> content management system – the content is stored in m4 files, which are
> transformed into HTML in advance, vs. more dynamic page generation in a
> typical content management system.
> https://web.archive.org/web/19990125090055/http://hire.com/ describes
> the software.
>
> https://web.archive.org/web/19980209192647/http://www.eds.com/careers/overview/cr_overview.shtml,
>
> https://web.archive.org/web/19990224005553/http://world4.hire.com/SVB/,
> and
>
> https://web.archive.org/web/19990422144616/http://www.careerstop.org/job.htm
> show remnants of customer pages created with those m4 macros.
>
> More at
>
> https://technologists.com/notes/2007/11/02/css-a-mans-got-to-know-his-limitations-2/
>
>
> Charlie
>
>
> --
> voice: +1.512.784.7526       e-mail: sauer@technologists.com
> fax: +1.512.346.5240         Web: https://technologists.com/sauer/
> Facebook/Google/LinkedIn/Twitter
> <https://technologists.com/sauer/Facebook/Google/LinkedIn/Twitter>:
> CharlesHSauer
>
>

-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

[TUHS] Re: M<some number> macros, wasRe: SCCS

[arnold]

"John Levine" <johnl@taugh.com> wrote:

> M4 was written in the 1970s by Kernighan and Ritchie in C ...

In private mail, BWK told me that it was DMR who wrote m4. He
then reimplemented it in Ratfor for "Software Tools".

Just to set the record straight. :-)

Arnold

[TUHS] Re: M<some number> macros, wasRe: SCCS

[John R Levine]

On Sun, 15 Dec 2024, arnold@skeeve.com wrote:
> "John Levine" <johnl@taugh.com> wrote:
>
>> M4 was written in the 1970s by Kernighan and Ritchie in C ...
>
> In private mail, BWK told me that it was DMR who wrote m4. He
> then reimplemented it in Ratfor for "Software Tools".
>
> Just to set the record straight. :-)

You might want to update the Wikipedia articles.

Regards,
John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Steffen Nurpmeso]

Marc Rochkind wrote in
 <CAOkr1zWnwM0xQjxyeco0RPOU1w_WRKRfXShOqbJgQg9V=55=bQ@mail.gmail.com>:
 |On Sat, Dec 14, 2024 at 6:43 PM Greg A. Woods <woods@robohack.ca> wrote:
 |> This is more of an aside, but as a long time and ongoing SCCS user I've
 |> wondered about the vc(1) command included in the SCCS tool suite.
 |>
 |> So I was hoping you (or anyone else reading) might be able to shed some
 |> light on its origins and maybe give, or point to, some examples of how
 |> it was intended to be used, or indeed how it ended up being used.
 |
 |I had completely forgotten about the vc command until I read this post. Vc
 |was a language-independent macro processor mostly concerned with excluding
 |or including lines of text based on the evaluation of logical expressions.
 |
 |Even though "vc" stands for "version control," it has nothing to do with
 |version control as that phrase is used nowadays. In the early 1970s where I
 |worked at Bell Labs, we (or at least I) used the term "release" to refer to
 |the different forms of a file as development proceeded, and "version" to
 |refer to ongoing variants of the file. For example, there might be a
 |version of some program for Southwestern Bell and a different version for
 |New York Telephone. Those two versions were contained in the same identical
 |sets of source files.
 |
 |I just looked again at my 1975 paper and I don't think the word "version"
 |appears anywhere. The terms "release" and "level" appear.
 |
 |I designed vc, but it was implemented by a college student who was with us
 |for the Summer. I credit a woman named Sabrina Feczko in my paper, and I
 |think it was her. As I mentioned, vc was totally standalone so Sabrina
 |didn't have to concern herself with all the squirrely code in the main part
 |of SCCS.
 |
 |Vc disappeared at some point. I don't think it was ever used, as it was

Jörg's (Schillig) SCCS ships with vc.  (His version lost some
limiting restrictions according to announcements, for example line
length.)  I have never used vc myself, so i cannot give examples.
(He worked quite intensively on his SCCS and the v6 file format in
his last year, wrote manuals, created tests etc.  I do not think
his changeset approach was completed.)

 |intended for mainframe programs that were being developed (but not
 |compiled) on PWB/UNIX. For UNIX development, C had its own macro processor.
 ...

--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)
|
|And in Fall, feel "The Dropbear Bard"s ball(s).
|
|The banded bear
|without a care,
|Banged on himself for e'er and e'er
|
|Farewell, dear collar bear

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike@gmail.com> wrote:

> Google ran on Perforce in the early days, then on an internal
> reimplementation that could scale better (long story). I believe that's
> still the case, as git continues to be desired by the users but unworkable
> as the core repo at the required scale. Clever hackery allows git to feel
> like it's being used, but it's all above what was at least at one time
> Perforce.
>
> My info could well be out of date, though.
>
> -rob
>
> Rob, can you tell us anything about Piper?

Marc

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Peter Weinberger (温博格) via TUHS]

https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-in-a-single-repository/
to start with

On Tue, Dec 17, 2024 at 10:54 AM Marc Rochkind <mrochkind@gmail.com> wrote:
>
>
>
> On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike@gmail.com> wrote:
>>
>> Google ran on Perforce in the early days, then on an internal reimplementation that could scale better (long story). I believe that's still the case, as git continues to be desired by the users but unworkable as the core repo at the required scale. Clever hackery allows git to feel like it's being used, but it's all above what was at least at one time Perforce.
>>
>> My info could well be out of date, though.
>>
>> -rob
>>
> Rob, can you tell us anything about Piper?
>
> Marc

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

Great, Peter... exactly what I was looking for.

Marc

On Tue, Dec 17, 2024 at 8:58 AM Peter Weinberger (温博格) <pjw@google.com>
wrote:

>
> https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-in-a-single-repository/
> to start with
>
> On Tue, Dec 17, 2024 at 10:54 AM Marc Rochkind <mrochkind@gmail.com>
> wrote:
> >
> >
> >
> > On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike@gmail.com> wrote:
> >>
> >> Google ran on Perforce in the early days, then on an internal
> reimplementation that could scale better (long story). I believe that's
> still the case, as git continues to be desired by the users but unworkable
> as the core repo at the required scale. Clever hackery allows git to feel
> like it's being used, but it's all above what was at least at one time
> Perforce.
> >>
> >> My info could well be out of date, though.
> >>
> >> -rob
> >>
> > Rob, can you tell us anything about Piper?
> >
> > Marc
>


-- 
*My new email address is mrochkind@gmail.com <mrochkind@gmail.com>*

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Rob Pike]

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

Not really. It was just the Perforce data model (which I still think is the
nicest I've used) and UI, with a completely new implementation on Google
infrastructure. To me and most others, it was the same as using Perforce.
It was a remarkable achievement.

-rob


On Wed, Dec 18, 2024 at 2:54 AM Marc Rochkind <mrochkind@gmail.com> wrote:

>
>
> On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike@gmail.com> wrote:
>
>> Google ran on Perforce in the early days, then on an internal
>> reimplementation that could scale better (long story). I believe that's
>> still the case, as git continues to be desired by the users but unworkable
>> as the core repo at the required scale. Clever hackery allows git to feel
>> like it's being used, but it's all above what was at least at one time
>> Perforce.
>>
>> My info could well be out of date, though.
>>
>> -rob
>>
>> Rob, can you tell us anything about Piper?
>
> Marc
>

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Greg A. Woods]

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

Thank you very much for your reply Marc.

One thing I left unstated in my question, and indeed in my 1988 question
as well, was more or less:  "If vc is just a macro processor, why might
I want to use it instead of any other available macro processor?"

Indeed that was an even more important question back then before there
was an open-source version of SCCS (with vc).  Back in 1988 I only had
access to a public SunOS machine, a public SCO Xenix machine, and
whatever Unix(-like) machines might be available at my current
workplace, and of course not all of them might have had SCCS installed.
As a C programmer I was already familiar with CPP of course, and having
been a Unix user since my earliest university courses I was also
familiar, at least in passing in 1988, with M4.  (One year later I had
my own little AT&T 3B2/400 running UNIX System V with SCCS!)

Having now finally read more about M6 thanks to your link to a copy of
CSTR#2, I see that vc is moderately more like M6 than M4 in its
simplicity, and as such it might be simpler to use in some contexts.

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Marc Rochkind]

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

On Tue, Dec 17, 2024 at 3:38 PM Greg A. Woods <woods@robohack.ca> wrote:

> One thing I left unstated in my question, and indeed in my 1988 question
> as well, was more or less:  "If vc is just a macro processor, why might
> I want to use it instead of any other available macro processor?"
>

Well, I don't remember much about why I designed vc. I was certainly very
aware of language independent macro processors. I had read McIlroy's 1960
paper when I was still in college. ("Macro instruction extensions of
compiler languages"
CACM, Volume 3, Issue 4) And, I knew about m6, too.

My guess is that there might have been two reasons for vc: That the other
choices were too complicated for the programmers we were supporting, and
that it was focused on excluding and including large blocks of text, which
as I recall, were awkward with m6 (and maybe m4).

In those days at Bell Labs we didn't think too hard about whether a new
command should be added to the system. Ironically, this was true even
though the UNIX kernel was a minimalist system and was as famous for what
it left out as for what it was in it. No management approval was necessary
for a new command; we just put it into /usr/bin on our PWB system (not the
research system) along with a man page. Although we were in NJ, it was
pretty much the wild west. Then, a few years later, the PWB system was
packaged up and released into the world.

Marc

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

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Larry McVoy]

On Sun, Dec 15, 2024 at 03:48:40PM -0500, Douglas McIlroy wrote:
> Unix originally imitated the Multics file system, but not the universal
> memory. mmap(2) weakly imitates universal memory by allowing a process
> to nominally incorporate a portion of a file into the process address space
> at page-level granularity. However, an update is guaranteed to be visible
> to the file and other processes only upon specific request.

That's not true with Sun's mmap().  It's coherent across process boundaries
and it's in sync with read()/write().  This is because Sun got rid of the
buffer cache and _only_ did file IO to/from the page cache.  You mapped
the actual page into your address space, if one process wrote it, the
other process will see it.

> Does anyone know whether there are implementations of mmap that
> do transparent file sharing? It seems to me that should be possible by
> making the buffer cache share pages with mmapping processes.

SunOS 4.0 did what I believe you are asking.

http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf
http://mcvoy.com/lm/papers/SunOS.vm_impl.pdf
-- 
---
Larry McVoy           Retired to fishing          http://www.mcvoy.com/lm/boat

[TUHS] Re: SCCS, TeamWare, BitKeeper, and Git

[Douglas McIlroy]

> well after Unix had fledged, its developers at CSRC found it necessary
> and/or desirable to borrow back a Multics concept: they named it mmap().

As far as I know no Research version of Unix ever had mmap.

Multics had a segmented universal memory. A process incorporated
segments into its address space The universal memory was normally
addressed via a hierachical segment-name directory. With enhancement
to provide for multisegment "files", the directory could serve as a file
system and file I/O became data transfer between segments.

Unix originally imitated the Multics file system, but not the universal
memory. mmap(2) weakly imitates universal memory by allowing a process
to nominally incorporate a portion of a file into the process address space
at page-level granularity. However, an update is guaranteed to be visible
to the file and other processes only upon specific request.

Does anyone know whether there are implementations of mmap that
do transparent file sharing? It seems to me that should be possible by
making the buffer cache share pages with mmapping processes.

Doug