Date: Wed, 24 Jun 2009 21:11:25 +0200 From: Roland Smith <rsmith@xs4all.nl> To: cpghost <cpghost@cordula.ws> Cc: freebsd-questions@freebsd.org Subject: Re: Versioning File System for FreeBSD? Message-ID: <20090624191125.GA75991@slackbox.xs4all.nl> In-Reply-To: <20090624175918.GA2948@phenom.cordula.ws> References: <20090624150422.GA2307@phenom.cordula.ws> <20090624163755.GA71757@slackbox.xs4all.nl> <20090624175918.GA2948@phenom.cordula.ws>
next in thread | previous in thread | raw e-mail | index | archive | help
--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Jun 24, 2009 at 07:59:18PM +0200, cpghost wrote:
> 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,
> > >=20
> > > is there anybody working on a versioning file system for FreeBSD
> > > right now?
> >=20
> > > 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.
> >=20
> > 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.
>=20
> Yes, that's one possibility. But just like Subversion (which I'm
> using extensively here), it's not really transparent.
What is? If you have to extend the API like you propose below, all
programs that want to use that feature have to be changed. So if you're
going around changing your program, why not have it interface to an existing
revision control that you are already familiar with? That seems a lot
easier that tacking revision control onto a filesystem!
Git is very good at efficiently storing the differences between
commits. And every copy of a directory under git control is a full-blown
repository, so you can experiment with a copy without fear of fouling up
your precious repository.
> 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.
>=20
> As an example: opendir(2) would grow an additional and optional
> argument "revision" to select either HEAD or some revision of the
> directory:
>=20
> DIR *dirp;
> dirp =3D opendir("/path/to/dir", 0); /* open /path/to/file at HEAD */
> dirp =3D opendir("/path/to/dir"); /* same as above, POSIX compat */
> dirp =3D opendir("/path/to/dir", 323); /* open dir at revision 323 */
>=20
> /* From here on, readdir() would retrieve /path/to/dir entries
> at the specified revision. */
>=20
> open(2) could open a file at an earlier revision:
>=20
> FILE *filep;
>=20
> /* open file in HEAD */
> filep =3D open("/path/to/file", O_RDONLY);
>=20
> /* open same path, but at revision 323 */
> filep =3D open("/path/to/file", O_RDONLY, /* 0666 */, 323);
There is some ambiguity here. Does 323 refer to a single file, or to the
state of its parent directory? If changing a file doesn't update the
version of its parent directory, then why have version numbers for
directories? On the other hand, if changing a file updates the revision
for the file and its parent directory, the revision for the root
directory will increase quite rapidly!
> 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.
>=20
> Modifying a file would also create new revisions (e.g. at each
> write(2), or at each close(2), that should be selectable).
I don't know what you want to do use this for, but a simple trick (used
e.g. by Pro/Engineer) is to have your application append a version
number after the filename (e.g. "foo.prt.1") that is incremented every
time the file is saved. This does waste some disk space (or provides
redundancy, take your pick).
=20
> 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.
VMS had a filesystem that uses versioning: [http://en.wikipedia.org/wiki/Fi=
les-11]
> 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/
>=20
> and there's a (unmaintained?) FUSE file system at:
> http://wayback.sourceforge.net/
>=20
> 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?
>=20
> > Roland
>=20
> -cpghost.
>=20
--=20
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)
--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)
iEYEARECAAYFAkpCel0ACgkQEnfvsMMhpyVtXQCggOD6s7POaFZSVxTRnHgzL/kO
uJoAoI5xsIZlsv3tr4kOEfmBX/vMJwYo
=u6gA
-----END PGP SIGNATURE-----
--FL5UXtIhxfXey3p5--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090624191125.GA75991>