The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
To: tuhs@tuhs.org
Subject: [TUHS] Re: SCCS roach motel
Date: Fri, 13 Dec 2024 17:57:55 -0500 (EST)	[thread overview]
Message-ID: <242CD757E4871441B72EA52F30CF4531.for-standards-violators@oclsc.org> (raw)

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:
-- SCCS and RCS don't (so far as I can tell) understand any
relation between files at all.  When I'm working on a real
project of any size, there is almost always more than one
file, and there are often changes that affect multiple files
at once: if an interface changes, the changes to definitions
and uses really all should be a single commit, logged in one
go and reversible as a single coordinated operation; if I
refactor code, moving it between files and perhaps adding
files or removing them, likewise.  It is possible to check
in a bunch of files at once and reuse the log message, but
I couldn't find a way to make it a true coordinated single
commit; and neither SCCS nor RCS has a way I could find to
record, as a structured commit, that files are added or
removed from a directory or directory tree.
-- CVS can track adds and deletes and can bundle changes
into a single commit on the command line, but the changes
are still stored individually per file.
-- None of the systems even tries to track file renames,
something I also do occasionally as programs and especially
documentation evolves.

It wasn't until I discovered Subversion that I started using
version control regularly in my own work.

Ironically, a few years after I began using svn for myself,
I ended up working in places that had great compost heaps
of RCS and CVS.  This would have made sense in the 1990s,
but it was in the 2010s, and continues in the 2020s.

I now use hg for my personal work, and have been attempting
to drag my workplace into using git if only so new hires
don't have to learn clumsy outdated stuff just to do their
jobs.  I expect to retire (not for this reason) before I
really succeed, though.

Norman Wilson
Toronto ON

             reply	other threads:[~2024-12-13 22:58 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-13 22:57 Norman Wilson [this message]
2024-12-13 23:19 ` Larry McVoy
2024-12-13 23:38   ` Warner Losh
2024-12-14  0:53     ` Larry McVoy
  -- strict thread matches above, loose matches on Subject: below --
2024-12-13 22:33 Norman Wilson
2024-12-17  0:21 ` andrew
2024-12-13 16:52 [TUHS] " Marc Rochkind
     [not found] ` <A6DE3D0A-8ED7-4E82-87CF-F2BC7AE11761@seiden.com>
2024-12-13 17:58   ` [TUHS] " Marc Rochkind
2024-12-13 21:09     ` Dan Cross
2024-12-14  1:11       ` Marc Rochkind
2024-12-14  1:27         ` Dan Cross
2024-12-14  1:39           ` Larry McVoy
2024-12-14  6:20           ` Marc Rochkind
2024-12-14  1:38         ` Larry McVoy
2024-12-13 18:06 ` Larry McVoy
2024-12-13 18:32   ` Marc Rochkind
2024-12-13 18:39     ` Marc Rochkind
2024-12-13 18:49       ` Larry McVoy
2024-12-13 18:55     ` Larry McVoy
2024-12-13 19:55       ` Henry Bent
2024-12-14 18:29         ` arnold
2024-12-14 18:59           ` Larry McVoy
2024-12-13 21:46     ` Clem Cole
2024-12-13 21:22 ` Rob Pike
2024-12-13 21:27   ` Rob Pike
2024-12-13 21:37     ` Aron Insinga
2024-12-13 21:40       ` Aron Insinga
2024-12-14  0:37 ` Luther Johnson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=242CD757E4871441B72EA52F30CF4531.for-standards-violators@oclsc.org \
    --to=norman@oclsc.org \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).