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

Re: Subversion vs. filesystems

From: Matthew O. Persico <persicom_at_acedsl.com>
Date: 2001-02-02 04:57:10 CET

Branko �ibej wrote:
>
> 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.
>

Before you go off and work to hard to re-invent the wheel, maybe you can
get some good ideas from the ClearCase site and its white papers. After
all, if I read this correctly, an "installable version-tracking
filesystem" smells a LOT like ClearCase to me. And I LOVED ClearCase,
but I had to leave it behind when I changed jobs three years ago. Sigh.

> --
> Brane �ibej
> 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/

-- 
Matthew O. Persico
    
"If you were supposed to understand it,
we wouldn't call it code." - FedEx
Shop online without a credit card
http://www.rocketcash.com
RocketCash, a NetZero subsidiary
Received on Sat Oct 21 14:36:21 2006

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.