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" <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
> 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
Received on Thu Jul 3 13:18:34 2003