Jim Blandy wrote:
> Kevin, you're the fellow who was talking about implementing a genuine
> mountable filesystem that tracked versions, right? What I think would
> be really useful along those lines would be to implement a filesystem
> on top of the *client* library --- you'd get a working directory where
> ordinary "rm", "mv", and "cp" would maintain the meta-information
> Subversion needs to do commits and updates. You could just use Emacs
> dired to mess around in your working copy, and it'd all Just Work.
That's the logical way to do it, so that you're not limited to mounting
only from a local directory.
> Detecting copies is a bit of a challenge, but I think GNU cp is a
> "memory mapped" cp: it maps the entire input file into memory, and
> then does a single write request to create the new file. This means
> that the write uses the exact same pages as the read. Perhaps the
> filesystem could notice which file the pages were coming from,
> recognize that a copy was in progress, and adjust the Subversion
> metainformation appropriately.
This would depend on having GNU cp too much. One of the ways to solve
this problem is to simply not have automatic commits, or at least
require an explicit "register" command for new files -- the ancestor
file could be passed as an argument.
I'd advise against trying to be too smart about detecting copies. From
my experience it creates more problems than it solves. For instance, you
can't distinguish between a "real" copy and a tool creating a backup
file; and you don't want to put backup files in the repository. A
.cvsignore-ish approach will work, but then you've just moved the magic
from a command to a filter -- which is almost certain to bite you someday.
It would be nice to have such a filesystem be completely transparent,
but in practice you'll use extra revision control commands anyway, or
you wouldn't need a versioning filesystem.
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:21 2006