9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: geoff@collyer.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Python filesystem
Date: Thu, 29 Nov 2001 15:07:42 -0800	[thread overview]
Message-ID: <20011129230748.5ECAC199D5@mail.cse.psu.edu> (raw)

C News has the shell script that locks the news system and augments
PATH.  INN tends more to the monolithic end of the program-design
spectrum.

Version numbers in file names have some well known problems.  They
actually come from systems older than VMS, including at least
RS(u)X-11 and Tenex/TOPS-20, which takes us back about 30 years.  All
the implementations I've seen use a semi-colon to separate the real
file name from the version number.  Among other warts, this means you
have to quote them when referring to them from pretty much any shell:

	rm 'foo.c;1'
or
	rm 'foo.c;'*

In addition, the parsing of these names has traditionally been weird.
For example, foo.c means foo.c;0 (or foo.c;-1, I can't recall) which
means the most recent version of foo.c, perhaps foo.c;6.  I think the
other one (;-1 vs.  ;0) means the oldest version of foo.c still on
disk, perhaps foo.c;5.  Rob's and pjw's ``The Hideous Name'' paper
elaborates on these and other naming botches.

The reality is that you end up with a directory full of dreck rather
quickly, then the nightly PURGE command runs and clobbers all but the
most recent two or three versions (it's settable by your local
administrator and can be as low as one, if memory serves), so you
don't end up with a full history on disk, which is just as well
because you wouldn't be able to find anything.  Version numbers of
related files are not kept in synch, so you can't just

	cp *';6' /tmp/compile

to get a consistent snapshot.  File server dumps get this right:

; cd /n/dump/2001/1127/sys/src/cmd/disk/rkfs
; lc
all.h       dat.c       errno.h     ialloc.c    mkfile      sub.c
auth.c      dat.h       fcall.c     iobuf.c     portdat.h   uid.c
chk.c       dentry.c    fcallconv.c lib.h       portfns.h   utime.c
con.c       devmulti.c  fns.h       main.c      porttime.c
console.c   devwren.c   fs.c        misc.c      print.c
; mkdir /tmp/compile
; bind -bc /tmp/compile .
; mk
8c -FVw fs.c
8c -FVw sub.c
[...]
8c -FVw devwren.c
8l  -o 8.out fs.8 sub.8 porttime.8 fcall.8 iobuf.8 dat.8 main.8 dentry.8 fcallconv.8 ialloc.8 misc.8 con.8 console.8 chk.8 uid.8 auth.8 devwren.8

It's possible that Dan's comment about granularity referred to space,
not time.  The various source control systems just store diffs between
versions, but if you edit (and thus rewrite) a source file, the whole
file gets written to the dump.  Given the low cost of storage, that
seems quite acceptable.  Storing diffs to save space probably mattered
more in the mid-1970s when SCCS was written.



             reply	other threads:[~2001-11-29 23:07 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-29 23:07 geoff [this message]
2001-11-29 23:26 ` George Michaelson
  -- strict thread matches above, loose matches on Subject: below --
2001-12-08 19:58 Doug McIlroy
2001-11-30  0:11 geoff
2001-11-30  3:10 ` William Josephson
2001-11-29 20:01 Russ Cox
2001-11-29 20:37 ` Dan Cross
2001-11-29 20:49   ` Boyd Roberts
2001-11-30 16:01     ` plan9
2001-12-01  4:44       ` Boyd Roberts
2001-11-29 14:49 Russ Cox
2001-11-29 19:28 ` Dan Cross
2001-11-29 20:02   ` Skip Tavakkolian
2001-11-29 20:05   ` Boyd Roberts
2001-11-29 10:23 rog
2001-11-29 10:54 ` Boyd Roberts
2001-11-28 20:36 David Gordon Hogan
2001-11-28 18:54 Russ Cox
2001-11-28 19:09 ` Matt
2001-11-28 21:46   ` Boyd Roberts
2001-11-29 12:24     ` Matt
2001-11-29  5:49   ` Lucio De Re
2001-11-29  6:30     ` Boyd Roberts
2001-11-29  6:31       ` George Michaelson
2001-11-29  7:10         ` Boyd Roberts
2001-11-29 11:26           ` Sam Holden
2001-12-06 16:56           ` Ralph Corderoy
2001-12-06 17:32             ` Boyd Roberts
2001-11-29 10:50       ` Lucio De Re
2001-11-29 11:06         ` Boyd Roberts
2001-12-06 15:59           ` Ralph Corderoy
2001-11-29  7:21     ` Skip Tavakkolian
2001-11-29  7:32       ` Steve Kilbane
2001-12-03 22:39         ` Laura Creighton
2001-12-07  9:36           ` Ralph Corderoy
2001-12-07 14:07             ` Laura Creighton
2001-11-29  7:37       ` Boyd Roberts
2001-11-29 11:10         ` Christopher Nielsen
2001-11-29 19:51         ` Skip Tavakkolian
2001-11-29 10:08     ` John Murdie
2001-11-29 10:37       ` Boyd Roberts
2001-11-29 12:03       ` Lucio De Re
2001-11-28 18:21 Russ Cox
2001-11-28 18:34 ` Matt
2001-11-28 18:18 Matt
2001-11-30  5:44 ` Quinn Dunkan

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=20011129230748.5ECAC199D5@mail.cse.psu.edu \
    --to=geoff@collyer.net \
    --cc=9fans@cse.psu.edu \
    /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).