From: Larry McVoy <lm@mcvoy.com>
To: reed@reedmedia.net
Cc: TUHS main list <tuhs@minnie.tuhs.org>
Subject: Re: [TUHS] V6 networking & alarm syscall
Date: Fri, 11 Jan 2019 14:18:53 -0800 [thread overview]
Message-ID: <20190111221853.GB7733@mcvoy.com> (raw)
In-Reply-To: <alpine.NEB.2.21.1901111528210.21728@t1.m.reedmedia.net>
On Fri, Jan 11, 2019 at 04:08:25PM -0600, reed@reedmedia.net wrote:
> Can someone tell me about SCCS behaviour when renaming/moving or
> deleting files? In particular, I think the select() code prior to
> 82/07/15 had different source filenames that no longer exist and the
> SCCS history was lost. Anyone else have ideas about this? I have
> noticed this with other SCCS spelunking where code was removed and then
> corresponding "s" files were missing -- but maybe that is just the way
> the systems that our current snapshots (McKusick discs) of this history
> were made from. Maybe sccs didn't checkout the history of deleted files
> by default (that is my guess).
Ah, SCCS is my jam (I rewrote it from scratch as part of BitKeeper).
SCCS didn't know about renames, it was strictly checkin/checkout.
BitKeeper added the concept of "inode" to SCCS though it was not
an integer like an inode in Unix, it was what we called a "key"
and it looked like
user@host|pathname|time_t|SCCS_chksum|64bits_of_dev_random
There was a key for each delta and the name of the file was an
attribute of the delta just as the contents were. So internally
we worked in keys but externally you used file names and it was
trivial to see where the file had lived.
Anyhoo, I digress, that's all BitKeeper, not SCCS. If you have
the SCCS history somewhere where I can get it I might be able to
find the file you want. Just point me at (I know I have that
set somewhere but no idea where they are).
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
next prev parent reply other threads:[~2019-01-11 22:19 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 23:12 Paul Ruizendaal
2019-01-11 0:17 ` Clem cole
2019-01-11 15:33 ` ron
2019-01-11 18:45 ` Clem Cole
2019-01-11 19:06 ` David
2019-01-11 22:08 ` reed
2019-01-11 22:18 ` Larry McVoy [this message]
2019-01-12 12:04 ` reed
2019-01-12 17:20 ` Clem Cole
2019-01-12 18:16 ` Eric Allman
2019-01-13 1:16 ` Madeline Autumn-Rose
2019-01-11 22:47 ` Clem Cole
2019-01-11 22:55 ` Eric Allman
2019-01-11 23:32 ` Warner Losh
2019-01-11 23:27 Paul Ruizendaal
2019-01-12 1:24 Noel Chiappa
2019-01-12 1:58 ` Dave Horsfall
2019-01-12 2:33 ` Warner Losh
2019-01-12 4:14 Noel Chiappa
[not found] <mailman.1.1547258402.6716.tuhs@minnie.tuhs.org>
2019-01-12 11:13 ` Paul Ruizendaal
2019-01-13 10:52 Paul Ruizendaal
2019-01-13 15:39 ` Warner Losh
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=20190111221853.GB7733@mcvoy.com \
--to=lm@mcvoy.com \
--cc=reed@reedmedia.net \
--cc=tuhs@minnie.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).