[TUHS] SCCS roach motel
Larry McVoy
lm at mcvoy.com
Sat Dec 14 09:19:47 AEST 2024
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 at 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
More information about the TUHS
mailing list