Versioning File System for FreeBSD?

[cpghost]

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/