14 Dec
2024
14 Dec
'24
5:38 a.m.
On Fri, Dec 13, 2024, 4:19 PM Larry McVoy <lm(a)mcvoy.com> wrote:
On Fri, Dec 13, 2024 at 05:57:55PM -0500, Norman
Wilson wrote:
That's a nice feature... Too bad we don't have it for the historic SCCS
trees.
Also, the historical SCCS trees lack metatdata about file renames (which
were done by moving the ,s files)...
Warner
I'll spare you how we made them unique, but I can tell you that in two
This is verging on COFF material, and I
won't mind if someone
moves the discussion thither:
Clem Cole:
As a satisfied user of SCCS (and later Bitkeeper), it's still my
preferred
choice.
====
I have to admit SCCS is one of the many pieces of software
I tried for a week or two > 40 years ago and abandoned because
I couldn't stand it. I don't think I ever tried RCS, because
I could see it didn't what I saw as the underlying problems.
CVS likewise. Subversion was the earliest version-control
system that felt usable to me.
What bugged me so much? The earlier systems were focussed
entirely (or for CVS, almost entirely) on individual files.
There was no way to link changes that affected more than one
file:
That was the problem that BitKeeper solved. There was an extra step,
bk commit, that glued all the files together in an atomic commit.
That and each commit was like a CVS tag, you can roll the history back
to any commit, no tags are needed. That's because while you think of a
revision as 1.5 or whatever, and BitKeeper had that interface, the real
name is a a provably unique key made up of
user(a)host|path/to/file.c|time_t|sccs_cksum
We called those "keys" and you could use a key any place you could use
a revision.
decades of BK use on every continent other than the
artic, we've never
had a key collision. Does require that you use DNS.
BTW, the CVS/SCCS/RCS importers guessed at commit boundaries and made
those systems yield commits. We looked at author, check in comments,
and time stamps, same author, same comments and within a short window,
that's the same commit.
--lm