14 Dec
2024
14 Dec
'24
11:43 p.m.
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(a)gmail.com <mrochkind(a)gmail.com>*
15 Dec
15 Dec
12:25 a.m.
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
12:53 a.m.
On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
At 2024-12-14T10:43:47-0700, Marc Rochkind wrote:
BitKeeper was 3 years into development by then. Here is the first BK
changeset:
ChangeSet(a)1.1, 1999-03-19 16:11:26-08:00, lm(a)lm.bitmover.com
BitKeeper gets stored in BitKeeper.
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.
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
1:13 a.m.
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(a)mcvoy.com> wrote:
On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden
Robinson wrote:
--
*My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*
At 2024-12-14T10:43:47-0700, Marc Rochkind
wrote:
BitKeeper was 3 years into development by then. Here is the first BK
changeset:
ChangeSet(a)1.1, 1999-03-19 16:11:26-08:00, lm(a)lm.bitmover.com
BitKeeper gets stored in BitKeeper.
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.
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
2:03 a.m.
On Sat, Dec 14, 2024 at 2:13 PM Marc Rochkind <mrochkind(a)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.
9:34 a.m.
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
10:15 a.m.
"Theodore Ts'o" <tytso(a)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.
3:43 p.m.
At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
Theodore Ts'o wrote:
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
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. 
4:05 p.m.
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(a)gmail.com> wrote:
At 2024-12-15T07:22:29+0000, Lars Brinkhoff wrote:
Theodore Ts'o wrote:
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
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.
17 Dec
17 Dec
9:53 p.m.
On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike(a)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
9:58 p.m.
https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-i…
to start with
On Tue, Dec 17, 2024 at 10:54 AM Marc Rochkind <mrochkind(a)gmail.com> wrote:
On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike(a)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
10:12 p.m.
Great, Peter... exactly what I was looking for.
Marc
On Tue, Dec 17, 2024 at 8:58 AM Peter Weinberger (温博格) <pjw(a)google.com>
wrote:
https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-i…
to start with
On Tue, Dec 17, 2024 at 10:54 AM Marc Rochkind <mrochkind(a)gmail.com>
wrote:
--
*My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*
On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike(a)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
18 Dec
18 Dec
3:05 a.m.
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(a)gmail.com> wrote:
On Mon, Dec 16, 2024 at 9:13 PM Rob Pike <robpike(a)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
15 Dec
15 Dec
6:44 p.m.
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.
16 Dec
16 Dec
2:12 a.m.
It appears that Lars Brinkhoff <lars(a)nocrew.org> said:
G. Branden Robinson wrote:
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.
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. 
1:02 a.m.
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(a)case.edu http://tiswww.cwru.edu/~chet/
1:12 a.m.
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.
2:24 a.m.
On Sun, Dec 15, 2024 at 2:12 PM Luther Johnson
<luther.johnson(a)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.
2:30 a.m.
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(a)gmail.com> wrote:
On Sun, Dec 15, 2024 at 2:12 PM Luther Johnson
<luther.johnson(a)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.
15 Dec
15 Dec
2:54 a.m.
"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(a)mcvoy.com
<mailto:lm@mcvoy.com>> wrote:
On Sat, Dec 14, 2024 at 12:25:56PM -0600, G. Branden Robinson wrote:
decentralized
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 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(a)1.1, 1999-03-19 16:11:26-08:00, lm(a)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(a)gmail.com <mailto:mrochkind@gmail.com>/ 
3:08 a.m.
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(a)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(a)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(a)1.1 <mailto:ChangeSet@1.1>, 1999-03-19 16:11:26-08:00,
lm(a)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(a)gmail.com <mailto:mrochkind@gmail.com>
3:18 a.m.
Am Sa., 14. Dez. 2024 um 20:14 Uhr schrieb Marc Rochkind <mrochkind(a)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
3:34 p.m.
[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(a)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.")
8:31 p.m.
On Sun, Dec 15, 2024 at 03:34:47AM -0600, G. Branden Robinson wrote:
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.
> > 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.
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.
10:33 p.m.
On Dec 15, 2024, at 6:31 AM, Larry McVoy <lm(a)mcvoy.com> 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!
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!
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.
16 Dec
16 Dec
12:04 a.m.
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
15 Dec
15 Dec
6:53 a.m.
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.quest…
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
2:16 p.m.
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(a)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.quest…
--
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)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(a)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
2:20 p.m.
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(a)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 :)
--
11:49 p.m.
On Sat, Dec 14, 2024 at 6:43 PM Greg A. Woods <woods(a)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
16 Dec
16 Dec
12:03 a.m.
On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind(a)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
12:57 a.m.
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
2:09 a.m.
New subject: M<some number> macros, wasRe: SCCS
On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind
<mrochkind(a)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
2:17 a.m.
New subject: M<some number> macros, wasRe: SCCS
At 2024-12-15T15:09:20-0500, John Levine wrote:
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=…
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
On Sun, Dec 15,
2024 at 10:49 AM Marc Rochkind <mrochkind(a)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. 
3:36 a.m.
New subject: M<some number> macros, wasRe: SCCS
On 12/15/2024 2:17 PM, G. Branden Robinson wrote:
At 2024-12-15T15:09:20-0500, John Levine wrote:
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=…
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/overv…,
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-limit…
Charlie
--
voice: +1.512.784.7526 e-mail: sauer(a)technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/LinkedIn/Twitter: CharlesHSauer
On Sun,
Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind(a)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.
7:51 a.m.
New subject: M<some number> macros, wasRe: SCCS
I found this TUHS thread from 2019:
https://tuhs.org/mailman3/hyperkitty/list/tuhs@tuhs.org/thread/GPFOZNHNX2JO…
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(a)technologists.com> wrote:
On 12/15/2024 2:17 PM, G. Branden Robinson wrote:
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=…
--
*My new email address is mrochkind(a)gmail.com <mrochkind(a)gmail.com>*
At 2024-12-15T15:09:20-0500, John Levine wrote:
>> On Sun, Dec 15, 2024 at 10:49 AM Marc Rochkind <mrochkind(a)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.
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/overv…,
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-limit…
Charlie
--
voice: +1.512.784.7526 e-mail: sauer(a)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
12:39 p.m.
New subject: M<some number> macros, wasRe: SCCS
"John Levine" <johnl(a)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
10:56 p.m.
New subject: M<some number> macros, wasRe: SCCS
On Sun, 15 Dec 2024, arnold(a)skeeve.com wrote:
"John Levine" <johnl(a)taugh.com>
wrote:
You might want to update the Wikipedia articles.
Regards,
John Levine, johnl(a)taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
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. :-) 
11:55 p.m.
Marc Rochkind wrote in
<CAOkr1zWnwM0xQjxyeco0RPOU1w_WRKRfXShOqbJgQg9V=55=bQ(a)mail.gmail.com>:
|On Sat, Dec 14, 2024 at 6:43 PM Greg A. Woods <woods(a)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
18 Dec
18 Dec
4:28 a.m.
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(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>
5:05 a.m.
On Tue, Dec 17, 2024 at 3:38 PM Greg A. Woods <woods(a)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
4
days inactive
7
days old
41 comments
22 participants
participants (22)
-
Alexis -
arnold＠skeeve.com -
Bakul Shah -
Charles H Sauer (he/him) -
Chet Ramey -
Dan Cross -
David Ryskalczyk -
G. Branden Robinson -
Greg A. Woods -
John Levine -
John R Levine
-
Larry McVoy -
Lars Brinkhoff -
Luther Johnson -
Marc Rochkind -
Martin Schröder -
Peter Weinberger (温博格) -
Rob Pike -
sjenkin＠canb.auug.org.au -
Steffen Nurpmeso -
Theodore Ts'o -
Tom Lyon