José Moreira wrote:
> Hello, i was wondering about the viability of the implementation of a
> 'version controller' filesystem (kernel level). I believe that something
> like that could be as or more useful that WinFS or similar. Anyone has
> an opinion?
There are voices that there are already way too many non-hardware drivers
(protocol drivers and filesystem drivers) in Linux. The danger of people that
do kernel level coding but are not aware of requirements for kernel-level
code is immense, in particular drivers for non-critical hardware (soundcards)
have been rumoured to be in bad state often.
Adding Subversion (possibly even with a BDB backend) to the kernel adds
incredible amounts of code, none of which was written with the assumption of
running with kernel privileges. Consider things like a null pointer: I
wouldn't mind a program relying on a segfault for dereferencing it, but at
kernel level that a big nono. Also, you can't rely on the OS cleaning up
after you when you exit. Stackspace is also scarce. There is almost no C
runtime. No assertion support exists to guarantee pre/postconditions.
Sorry, but rather start hacking on one of those facilities that finally export
a decent API for implementing filesystems to userspace and then create the
gruecode to connect that to a Subversion backend.
A totally different approach would be to use the FAM or similar things to
auto-commit things, which could be implemented in 100% userspace and even
portably so (assuming FAM and Subversion were already ported).
IMHO
Uli
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Feb 18 09:12:17 2005