Mapping the reposiutory to a filesystem has been on my wishlist for a
long tiime -- practically from day 1 -- but I decided that to get any
kind of consistencyfrom an autoversioning-like writable implementation,
you need at least exclusive lockingin Subversion. So I'll wait until we
get that before going any further with FS mapping.
Daniel_Patterson@national.com.au wrote:
>Hello all,
>
> An idea germinated earlier today, I thought I'd drop this one to the
>mailing list. I do not have
> time to implement it myself, but someone may pick it up and run with it.
>
> It might be nice to be able to access the Subversion filesystem using
>various already
> existing clients. I envisage this being read-only, or autoversioned
>(al-la what we have with WebDAV)
> access.
>
> This can kind of currently be done with the WebDAV interface, using Web
>Folders on Win32 and DavFS on
> Linux. I am imagining a stack of other interfaces, such as the
>following:
>
> 1. A CIFS method of accessing the svn repository. Samba has a VFS layer
>that allows you to
> create a programmatic filesystem that could talk to a subversion
>repository and serve it out
> as a CIFS share to CIFS clients (i.e. Win32 boxen).
>
> 2. An NFS server that can talk to a Subversion repository, allowing you
>to mount your subversion repository
> or some part of it onto Unix boxes.
>
> 3. A local filesystem kernel driver that would let you do something
>like:
>
> mount -t svn file:///var/svn/repos/myrepos/trunk /opt/myapp
>
> Uses I can see for tools such as these:
>
> a) Like we have with WebDAV, allow svn-clientless access to the
>repository, without requiring WebDAV.
> b) Allow "live" views of various bits of the repository, i.e. commits
>to trunk/ appear immedietly in the
> OS filesystem, which can then be served to end users (i.e. an
>Apache website, etc).
>
> This thought was partly motivated by Rational ClearCase and it's MVFS
>filesystem driver and the "Dynamic Views"
> feature. With Clearcase in that configuration, network traffic is heavy,
>I don't think Subversion would be
> any worse.
>
> Understandably, I imagine there are lots of things to consider (how to
>read file data block-wise, locking, etc), I'm
> leaving it up to the implementor to work that stuff out (*hand wavy
>brush-off*).
>
>daniel
>
>
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 1 10:22:52 2004