Re: Yet another linux filesytem: with version control

Alexander Viro (viro@math.psu.edu)
Tue, 24 Jul 2001 02:06:12 -0400 (EDT)


On Mon, 23 Jul 2001, Larry McVoy wrote:

> That said, I'd really urge people to listen to Rik, he has the right idea
> with the user level NFS idea. There is no good reason and a lot of bad
> reasons to put this stuff in the kernel.

> > Distributed filesystems like Coda seem to get pretty close
> > to having revision control anyway. They need something like
> > it for conflict resolution.
>
> Yeah! No kidding. If Coda had this I think there is a reasonable chance
> that most SCM systems would go away. Certainly the trivial ones would.

CODA servers tend to be simpler than NFS ones (stateful protocol,
commit-on-close, all file IO handled by local fs code, you name it).
Full-blown Venus is, indeed, a lurking horror from beyond, but that's a
different story - nightmarish stuff is in the distributed fs part. As a
glue for userland fs CODA wins hands down (BTW, that goes not only for
simplicity of code, but for performance and deadlock avoidance reasons).

There's a whole shitcan of worms around the semantics of versioned
fs, though - e.g. what happens if you create a link to an old version of
file? What happens if you rename an old version away? What happens if you
rename _over_ it? There are obvious answers to that (e.g. all versions
except the last one are read-only and can be freely moved around or removed;
all association between them is semblance of names), but I doubt that
any of the easy variants will satisfy those who want that stuff. Personally,
I'd go for "you can take a read-only snapshot of a subtree and then bind
its parts anywhere you want", but that's not the only variant and I really
doubt that _any_ variant would satisfy everyone.

No matter what implementation you choose, semantics will be a fscking
minefild and I'd rather _not_ see that flamewar on l-k. If somebody cares
to set a maillist - great, but let's keep it separate from l-k. This stuff
has a potential for flamewar worse than devfs, forked-files, bk licensing
and CML2 ones combined (and is very likely to resurrect the first two, in
bargain).

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/