Date: Wed, 24 Jun 2009 19:59:18 +0200 From: cpghost <cpghost@cordula.ws> To: Roland Smith <rsmith@xs4all.nl> Cc: freebsd-questions@freebsd.org Subject: Re: Versioning File System for FreeBSD? Message-ID: <20090624175918.GA2948@phenom.cordula.ws> In-Reply-To: <20090624163755.GA71757@slackbox.xs4all.nl> References: <20090624150422.GA2307@phenom.cordula.ws> <20090624163755.GA71757@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jun 24, 2009 at 06:37:55PM +0200, Roland Smith wrote: > On Wed, Jun 24, 2009 at 05:04:22PM +0200, cpghost wrote: > > Hi, > > > > is there anybody working on a versioning file system for FreeBSD > > right now? > > > I don't care if it is native or a layer, geom-ified, fuse-based, > > or even if it uses subversion as its backend, as long as it > > provides some kind of transparent versioning. > > You could try devel/git? It's not a file system, but a very efficient > directory content tracker/version control system. One of the things I > use it for is to keep a certain directory in sync between a desktop and > a laptop. It works equally well with text or binary files. Yes, that's one possibility. But just like Subversion (which I'm using extensively here), it's not really transparent. > Or maybe http://www.nongnu.org/libsqlfs/ will do what you want? Haven't > tried that, though. But does it really support versioning? I was actually thinking of a real versioning file system, with an extended POSIX API (yet to be defined), to access all revisions of a file system, just like with Subversion revisions. As an example: opendir(2) would grow an additional and optional argument "revision" to select either HEAD or some revision of the directory: DIR *dirp; dirp = opendir("/path/to/dir", 0); /* open /path/to/file at HEAD */ dirp = opendir("/path/to/dir"); /* same as above, POSIX compat */ dirp = opendir("/path/to/dir", 323); /* open dir at revision 323 */ /* From here on, readdir() would retrieve /path/to/dir entries at the specified revision. */ open(2) could open a file at an earlier revision: FILE *filep; /* open file in HEAD */ filep = open("/path/to/file", O_RDONLY); /* open same path, but at revision 323 */ filep = open("/path/to/file", O_RDONLY, /* 0666 */, 323); unlink(2) would remove an entry from a directory, and bump the revision of the directory. Accessing that path from the new revision wouldn't be possible, but the file would still be there in an earlier revision. Modifying a file would also create new revisions (e.g. at each write(2), or at each close(2), that should be selectable). Of course, there would be additional API calls to traverse the list of revisions, to access meta data (properties?, tags?, commit logs?, ...) etc., so that the file system remains manageable. I didn't try them (yet), but on Linux, there are some experimental versioning file systems like: http://www.ext3cow.com/Welcome.html http://tux3.org/ and there's a (unmaintained?) FUSE file system at: http://wayback.sourceforge.net/ all of which differ in the way POSIX API should be extended and the semantics for versioning. But there's apparently nothing yet in the works for FreeBSD. Perhaps some layer on top of existing file systems, or an extension of UFS/FFS that stores versioning meta data directly at the block level? > Roland > -- > R.F.Smith http://www.xs4all.nl/~rsmith/ > [plain text _non-HTML_ PGP/GnuPG encrypted/signed email much appreciated] > pgp: 1A2B 477F 9970 BA3C 2914 B7CE 1277 EFB0 C321 A725 (KeyID: C321A725) -cpghost. -- Cordula's Web. http://www.cordula.ws/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090624175918.GA2948>