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

Re: Mounting Subversion into the filesystem

From: Timothee Besset <ttimo_at_idsoftware.com>
Date: 2003-07-03 13:17:35 CEST

If you are interested in filesystem work around svn, you might want to
start looking at yam.

The website doesn't have much stuff yet, as I've been too busy to cleanup
the design docs for a public release. Nethertheless I can get you more
info if you reach me in private. I already started implementing
side-features for SCM using subversion relying on filesystem mounts.


On Thu, 3 Jul 2003 10:54:09 +0200
"Thomas Goorden" <Thomas.Goorden@lantis.be> wrote:

> > On Fri, 2003-07-04 at 00:15, Daniel Patterson wrote:
> > > One way that the original posters requirement *could* be met might
> > > be to use davfs (http://dav.sourceforge.net/) to mount the SVN
> > > repository into the webservers filesystem. This takes care of the
> > > "live" requirement, but adds an unnecessary layer in the middle
> > > (which could be a performance hit).
> >
> > It might be nice to be able to do:
> >
> > mount -t svnfs -o repopath=/trunk /var/svn/repos1 /mnt/svnrepos1
> >
> > It could be read-only initially, but the possibilities are endless
> Quoting from "Subversion: The definitive guide (Appendix D: WebDAV and
> Autoversioning)":
> >Server-side working-copy model
> >
> > Some DeltaV servers support the ability to create a virtual
> "workspace" on the
> > server, where all of your work is performed. Clients use the
> > method to create a private area, then indicate they want to change
> specific VCRs
> > by "checking them out" into the workspace, editing them, and "checking
> them in"
> > again. In HTTP terms, the sequence of methods would be CHECKOUT, PUT,
> > CHECKIN. After each CHECKIN, a new VR is created, and edited VCR's
> contents
> > now "point to" the latest VR. Each VCR has also has a "history"
> resource which
> > tracks and orders its various VR states.
> and
> > Autoversioning
> >
> > For many, this is the "killer" feature of DeltaV. If the DeltaV server
> supports this
> > feature, then basic WebDAV clients (i.e. those unaware of versioning)
> can still write
> > to the server, and the server will silently perform versioning anyway.
> In the simplest
> > example, a ignorant PUT from a basic WebDAV client might be translated
> by the
> > server as a CHECKOUT, PUT, CHECKIN.
> The first concept would be perfect for (release == deployment) scenarios
> and is exactly what I was talking about. I see this working in two ways:
> 1. Each release triggers deployment of the new material to a
> configurable location. This would be similar to the cron job "K" was
> talking about, except it'd have to be triggered from within the DeltaV
> server and not through an outside mechanism.
> 2. Make it possible to mount/map a directory onto the DeltaV server. In
> this case there wouldn't even be 2 copies of everything, the DeltaV
> server just looks like an "innocent" filesystem on the outside. This is
> what Daniel talks about.
> The autoversioning seems to be the natural companion to this system: it
> would make for perfect interoperability of "plain" WebDAV clients,
> filesystem based programs (like a deployment server), but on the
> back-end you get a compeletely versioned system.
> A project-manager's wet dream.
> Granted, this probably gives quite some overhead (especially in the
> second "mount" scenario), but I see this system only being used during
> development anyway... So who cares?
> Since Subversion implements DeltaV: How have these two proposals been
> approached so far?
> Regards,
> Thomas
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 3 13:18:34 2003

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.