[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnfs

From: Archie Cobbs <archie_at_dellroad.org>
Date: 2004-10-08 15:45:51 CEST

Karl Chen wrote:
> Hi, I am thinking about writing a file system for Linux that
> transparently use a Subversion repository or working copy. Since
> this will do a lot of extra commits, I think the "Eric goes to
> lunch"/svk distributed model will work well together when editing
> source code. It will transparently add useful versioning to many
> applications (without needing svk-type two-layer version control).
> Comments/suggestions?

Crazy^H^H^H^H^HInteresting idea!

> % diff -u main.C main.C@123 # like 'svn diff -r 123 main.C'

This implies every revision foo@NNN appears in the directory.. ?
Might get crowded... maybe put them in a .revisions subdirectory?

Where do properties appear? You could create a ".properties" subdirectory.

> - whether to automatically commit each action; this could be a
> run-time per-WC option
> - whether to automatically add or ignore a new file? e.g., object
> and temporary files should be ignored. Will the svn:ignore
> feature be good enough to handle this?

You could commit whenever there were no longer any open files
in the directory (this could take arbitrarily long to happen).

You could also just commit every N seconds.

How would you handle hard links? Ownership? Permissions? Locking?
Special files? You'd need to store some meta-information in the
repository for stuff like that.. perhaps in special svnfs: properties.

> - is it easy to arrange for 'cp a b' to be 'svn cp a b', if cp is
> implemented as 'cat a > b'?

You could hash the contents of each file present in a directory.
This would allow you to detect copies.

More generally, keep all files in a suffix tree or whatever, and
new files would be auto-correlated with the nearest existing file
revision that was close enough to be heuristically determined to
be an ancestor.

> - how to support normal svn clients; perhaps instead of the mount
> above use:
> svn co http://svn.quarl.org/repos/foo ~/foo-wc
> svnmount ~/foo-wc ~/foo
> Without the intermediate WC, svnfs would have to operate in
> automatic-commit mode.
> For example, I have my /etc stored in a Subversion repository.
> But often this WC is manipulated by scripts that create, move,
> delete files, and I have to manually tell svn that and also
> commit; I would rather just have it be automatically versioned.

This might actually be a more useful idea. svnfs would be a file
system "layer". It would convert e.g. "mv x y" into "svn mv x y",
"cp a b" into "svn cp a b", etc. Underneath, it would just be
manipulating a WC. When you're done, unmount the file system and
commit (or use some special svnfs-specific command).

On the other hand, this doesn't have to be implemented as a file
system. You could simply have a daemon that did periodic "snapshots"
of some directory hierarchy and committed them automatically. This
would be useful for backing up /etc .. e.g., have a snapshot taken
and commited to the repository at 3am every night.


Archie Cobbs * CTO, Awarix * http://www.awarix.com

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 8 15:46:18 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.