Mounting Subversion into the filesystem [was Re: Proper way to set-up SVN]

[Daniel Patterson <da...@adaptiveinternational.com>]

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).

Oo, a wishlist item just appeared in my head :)

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 :)
(POSIX ACL's through attributes....)

daniel


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Mounting Subversion into the filesystem

[Timothee Besset <tt...@idsoftware.com>]

If you are interested in filesystem work around svn, you might want to
start looking at yam.
https://zerowing.idsoftware.com:666/yam-web/index.html

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.

TTimo

On Thu, 3 Jul 2003 10:54:09 +0200
"Thomas Goorden" <Th...@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
> MKWORKSPACE 
> > 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

RE: Mounting Subversion into the filesystem

[Thomas Goorden <Th...@lantis.be>]

> 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
MKWORKSPACE 
> 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