From owner-freebsd-questions@FreeBSD.ORG Thu Jun 25 13:41:55 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 196131065672 for ; Thu, 25 Jun 2009 13:41:55 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.freebsd.org (Postfix) with ESMTP id 3C19B8FC0A for ; Thu, 25 Jun 2009 13:41:54 +0000 (UTC) (envelope-from cpghost@cordula.ws) Received: from phenom.cordula.ws (phenom [192.168.254.60]) by fw.farid-hajji.net (Postfix) with ESMTP id 583D12E363; Thu, 25 Jun 2009 15:41:52 +0200 (CEST) Date: Thu, 25 Jun 2009 15:41:53 +0200 From: cpghost To: Roland Smith Message-ID: <20090625134153.GB882@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> <20090624235945.GA83599@slackbox.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090624235945.GA83599@slackbox.xs4all.nl> User-Agent: Mutt/1.5.19 (2009-01-05) Cc: freebsd-questions@freebsd.org Subject: Re: Versioning File System for FreeBSD? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 13:41:55 -0000 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/