Versioning File System for FreeBSD?

[Roland Smith]

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?

> > > 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.
> > > 
> > > 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).
> 
> Yes, that's always possible. But that would defeat transparency.

Why? Larger number==later file. How more transparent could it be?
 
> 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. 

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.
> > 
> > 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.

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090624/932be334/attachment.pgp