Date: Thu, 25 Jun 2009 01:59:45 +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: <20090624235945.GA83599@slackbox.xs4all.nl> In-Reply-To: <20090624215734.GA3720@phenom.cordula.ws> References: <20090624150422.GA2307@phenom.cordula.ws> <20090624163755.GA71757@slackbox.xs4all.nl> <20090624175918.GA2948@phenom.cordula.ws> <20090624191125.GA75991@slackbox.xs4all.nl> <20090624215734.GA3720@phenom.cordula.ws>
next in thread | previous in thread | raw e-mail | index | archive | help
--6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2009 at 11:57:34PM +0200, cpghost wrote: > Quite true! >=20 > I see even more ambiguity here: What about a versioned file pointed > to by hard links from two versioned directories? The more I think about it, the more problems I can see. Look e.g. at symbolic links. Or looking from the vc side, what about branches (checking out an older version of a file and editing it). Does it automatically become the new head, or are concurrent branches allowed? =20 > And even if the semantics were absolutely sound (can they be?), all > this meta data really needs to happen on a block level, e.g. how > described in that paper. I really wonder if combining a filesystem and a version control system is a good idea? > > > unlink(2) would remove an entry from a directory, and bump the revisi= on > > > 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). > >=20 > > 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 > Yes, that's always possible. But that would defeat transparency. Why? Larger number=3D=3Dlater file. How more transparent could it be? =20 > And there's another problem here: what if two processes concurrently > save (commit?) the same file, and there's a merging conflict? I'd say that two processes should _never_ open the same file for writing at the same time. Since the contents of the file are opaque to the file system but not to the programs, it is impossible for the filesystem to fix merge conflicts.=20 If you have multiple programs working together only one should write to the file in question. The others should communicate with the writing program via IPC. > > > 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. > >=20 > > VMS had a filesystem that uses versioning: [http://en.wikipedia.org/wik= i/Files-11] >=20 > I was thinking about this before starting this thread. But file > versioning (as opposed to full versioning that also includes > directory versioning) is probably relatively easy to implement. > At least, its semantics are unambiguous. Indeed. It seems the VMS filesystem just tacks a semicolon and a nummer on to the filename. Roland --=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) --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.12 (FreeBSD) iEYEARECAAYFAkpCvfEACgkQEnfvsMMhpyWm5QCaAlPzec7wx4o3Y+u4ifH0BIcD K7oAniywaJ3T0ddIWwTayPgjsoYijjBJ =2tq0 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090624235945.GA83599>