Date: Thu, 25 Jun 2009 15:41:53 +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: <20090625134153.GB882@phenom.cordula.ws> In-Reply-To: <20090624235945.GA83599@slackbox.xs4all.nl> 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> <20090624235945.GA83599@slackbox.xs4all.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 25, 2009 at 01:59:45AM +0200, Roland Smith wrote: > On Wed, Jun 24, 2009 at 11:57:34PM +0200, cpghost wrote: > > Quite true! > > > > 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? > > > 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? After a good night's sleep, and rethinking the whole concept, I agree that this is not such a good idea after all. At least not until I fully understand how (directory) versioning actually is supposed to work semantically AND under the hood. I'll stick to subversion (and will try git and hg as well), until I find a better solution. > > 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. Right! > 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. Serializing file access? Yes, that makes sense. > > > > 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/Files-11] > > > > 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. Yep, that's one way to do it. If you're willing to go to the block level, I could imagine the inode of a versioned file linking to versioned direct / indirect blocks, i.e. one inode linking to more than just one ("physical") file. To keep things simple, the inode could link to a circular buffer of N (direct/indirect block links). Those versioned files could also COW-share blocks, but that's nothing conceptual, just an optimization. That would be pure file versioning: directories are linking to the inode, and each inode would potentially refer to N revisions of a file. But if it makes sense or not is something else altogether. Thanks for the great brainstorming. Things are clearer to me now. ;-) > 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?20090625134153.GB882>