[TUHS] Re: SCCS roach motel

[Larry McVoy <lm@mcvoy.com>]

On Fri, Dec 13, 2024 at 05:57:55PM -0500, Norman Wilson wrote:
> 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@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.

I'll spare you how we made them unique, but I can tell you that in two
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