Re: [9fans] Python filesystem

["Boyd Roberts" <boyd@fr.inter.net>]

> 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.

So does /n/dump as it only makes copies of blocks that have been modified.
The various versions are held together by the tree.  An unmodified block
is shared by all 'versions' of the file.

> This is what /n/dump does, execpt that /n/dump has a non-arbitrary
> level of granularity, which seems to be what is missing.

IIRC it does:

    /n/dump/2001/1129[a-z]

> 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

No this is horrible.  It falls straight out of /n/dump.

> The files have standard namespace(6) format.

Yes this is right.  You have file(s) that build a namespace(s)
and then you type:

    mk [ dist ]

and it just does it.

> 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.

Err, I'd stick to small n formats otherwise it just complicates the problem.

> 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.

/n/dump already does it during the dump.  Just turn it on via bind(1).

> 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.

No /n/dump already does it.  VMS file versions are a disaster.  Qids
are a much better idea, but it is a slightly different problem.

> What do we lack then?

We lack a mod to bind(1)/9P, some namespace files and some mkfiles.

It all falls straight out of /n/dump.

I'm not sure how a copy-on-write bind would fit into 9P, because
I haven't looked at 9P for a long time, but I'm assuming it's
doable; a bit like writable union directories.