9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Dan Cross <cross@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Python filesystem
Date: Thu, 29 Nov 2001 14:28:33 -0500	[thread overview]
Message-ID: <200111291928.OAA25251@augusta.math.psu.edu> (raw)
In-Reply-To: <20011129144905.6695D19A9F@mail.cse.psu.edu>

In article <20011129144905.6695D19A9F@mail.cse.psu.edu> you write:
>	echo 'usage: cvshell' >[1=2]

cvshell?  I've noticed a trend in Plan 9 to write compressed word
sequences using all letters, eg, cvsshell.  Now the question arises, is
this a Freudian slip, or an intentional jab at CVS?  :-)

I was thinking about this problem, and one nice thing about RCS/CVS/
whatever is that they store deltas of a file up to a current version.
This is what /n/dump does, execpt that /n/dump has a non-arbitrary
level of granularity, which seems to be what is missing.  Labelling
versions could be handled by a meta-database of files at another level;
eg, have a directory versions/ with sudirectories and files
corresponding to the versions of files that make up a release.

	versions/1/2/1/vers

The files have standard namespace(6) format.  Or maybe even be mkfs
prototypes.  Anyway, there's the ability to make release from arbitrary
things on the dump; just create a namespace with all the named files in
it, and tar it up.

But what about arbitrary commitment to the dump?  It struck me that an
filesystem that mimmicked VMS file versions could give you that.
create(2)'ing a file would make a new version, which was really a delta
on the old.  If the deltas were kept in normal RCS-like files, and
reconsitituted on the fly by the revison control fs, you'd get
basically RCS/CVS, but with the ability to edit things using `normal'
tools; no more CVS commands or strange tools to manipulate the
repository.  Files would be named, eg, file.c;1.4.3.

What do we lack then?  Locking and management of metadata?  There's
probably a way around those, as well.  The revision control FS isn't
well formed for saving; maybe a better solution would be to echo a
revision number into a ctl or new file, and then have that create a new
delta.  Write the file into it, and let the FS take care of picking out
the delta and storing it.  Perhaps a metadata file could be associated
with every file.  eg, foo.c;meta, foo.c;1.0, etc.

Maybe I'm smoking my hair; these thoughts are only half formed.

	- Dan C.



  reply	other threads:[~2001-11-29 19:28 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-29 14:49 Russ Cox
2001-11-29 19:28 ` Dan Cross [this message]
2001-11-29 20:02   ` Skip Tavakkolian
2001-11-29 20:05   ` Boyd Roberts
  -- 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 23:07 geoff
2001-11-29 23:26 ` George Michaelson
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 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=200111291928.OAA25251@augusta.math.psu.edu \
    --to=cross@math.psu.edu \
    --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).