Kevin Pilch-Bisson wrote:
> Okay on to file systems.
>
> I was thinking that it would be nice to have a file system which does
> the following.
I worked on such a file system (actually a file server) for 4+ years, so
I have some idea about the problems involved.
> 1) Stores all the revisions (including history) of a file. The same as
> subversion does, but implemented at the file-system layer, so that any
> time a change is made, it is in a way automatically committed.
Oops. How do you know when a change was made? After each write, after
each close, or after all handles to a file have been closed? What about
ch{mod,acl,usr,grp}?
Another thing you have to think about is what to do with temporary
files. Backup files from editors, object and other temporary files from
compilers, etc. If you automatically place those under version control,
you'll end up with all sorts of crud in the repository.
In general it's a bad idea to try to guess when a change is complete.
Whatever approach you take, it'll be wrong for some tool/use model. The
only safe way I know is to have the user state explicitly when a change
is complete; e.g., use an extended API, say filesystem-specific IOCTLs,
then write a command-line tool on top of those.
> 2) Beyond that it should allow all the normal cvs type operations,
> tagging, diffs, retrieval of past labels/versions, etc.
Oops again. That's not the filesystem's job. All of those belong to the
extended API.
> _AND_ it should
> allow retrieval of a file (or tree) based on a timestamp (so you could
> say something like: make my system the way it was yesterday before I
> made all these crazy changes to it).
This is a normal CM operation. You also want to move a whole filesystem
(or subtree) to another branch, etc.
On the other hand, you may want to think about exposing the version tree
in the filesystem, say from a special kind of mount point. The
possibilities are endless.
> 3) In addition it would be nice to have tools to move old parts of the
> tree onto permanent storage so that disk-space is not wasted
> indefinitely. I.e. move the repository to tape/CDROM/etc, then replace
> it with a sort of new repository with the current files as the
> originals.
Now /that/ is something I'd like to see in Subversion. Right now the SVN
filesystem design doesn't allow something like that, since committed
nodes are immutable, but I'm sure we could change the design slightly to
support archiving of old versions.
The simplest way (and possibly a first step) would be to simply allow a
file's text to be stored offline (i.e., besides having "fulltext" and
"younger" file nodes, we'd also have "offline" nodes). This would keep
all history and tree info intact, just make the contents unavailable.
Hmm. Must remember to put this in IDEAS.
> What does everyone think of a file system like this. Personally I think
> it would be extremely useful! Is anyone interested in helping me learn
> enought about file systems and version control to actually implement
> something like this?
It's definitely a useful concept. I've been thinking about having
something like ClearCase's dynamic views for Subversion -- these are a
bit like a versioned filesystem, but only accessible over the network.
They're useful because a client doesn't have to create a local working
copy. This can be a significant savings (in disk space /and/ network
traffic) if your source tree is 1 GB and you have to work on three
branches at once, which I happen to be doing right now at work. :-)
Kevin, if you want to work on this, let me suggest you stay away from
kernel code and Linux specifics for now. I think a good approach would
be to write a Samba VFS module on top of Subversion; the benefits are
that you stay in userland (a good thing for initial development) and
you're not bound to a single platform. It's been some time since I last
took a hack at Samba, but I'm sure you'll be able to find your way
around. If not, holler.
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:19 2006