> 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
Received on Thu Jul 3 10:55:19 2003