You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2001/07/06 22:13:29 UTC
mod_dav_svn
I'm preparing to jump into ra_dav and mod_dav_svn. In particular, I'd
like to get properties working over the wire. So I've spent all day
re-reading the deltaV spec & examples, and Greg's quasi-outdated
document on how deltaV maps to Subversion:
http://www.webdav.org/deltav
http://subversion.tigris.org/webdav-usage.html
I know that Greg Stein isn't listening to email right now, due to more
important engagements (:-)), but he may see some of these threads next
week. Also, it's possible that Joe Orton may know a lot about this.
First, I'd like verification that I understand what mod_dav_svn is
really doing. It seems like a deltaV server has the job of creating
lots of "temporary" URLs as way of continually building up state with
the client. (Since HTTP is a stateless protocol, I guess this is all
it can do!)
mod_dav_svn puts all these temporary URLs into the $svn namespace:
$svn/act/URL/UUID activities (fs transactions in progress)
PROPFIND, DELETE (abort), MERGE (commit)
$svn/his/[node-id] versioned history resources
$svn/ver/[node-id]/[path] versioned resources -- immutable!
PROPFIND, GET, REPORT (only read-only ops)
$svn/wrk/[activity]/[path] working resources (being edited)
$svn/blin baseline resources (not done) -- svn revisions?
$svn/bsel
$svn/bhis
So my first question was originally: where is mod_dav_svn storing all
this stuff? On disk somewhere?
But then I noticed that many of the temporary resources above are
defined in terms of libsvn_fs node-ids -- the fs is doing all the
necessary storage.
But what about the resources that depend on 'activities', like
$svn/act/ and $svn/wrk/ stuff? My intuition is that an activity's
name would just be equal to the libsvn_fs transaction name -- but then
Greg's spec says that it's a UUID chosen by the client?!?
This indicates to me that our DAV activities aren't persistent. If
Apache crashes, there's no way to examine an fs transaction in
progress again, because mod_dav_svn has "forgotten" about it, and all
the working resources it contains. Is this really true?
It's important to me, because someday we may deliberately *want* to
leave fs transactions lying around for a long time... for workflow
purposes (say, a supervisor needs to approve the txn before committing
it.)
Looking to bounce ideas off another brain.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_dav_svn
Posted by Karl Fogel <kf...@collab.net>.
Ben Collins-Sussman <su...@collab.net> writes:
> > Yup, mod_dav_svn persists activities using an extra 'activities'
> > databases (just using APR's dbm interface) in the repostiry, see
> > mod_dav_svn/activity.c.
>
> Holy cow, there are some activity databases being dumped right into
> the repository directory!
>
> $ ls /www/svn/sussman-repo/
> README* activities.dir activities.pag db/
>
> Well, that explains it. :-)
Sure does, heh.
I wonder why README is executable (can APR_OS_DEFAULT do that?).
Also, wonder if we shouldn't have a dav/ directory for activies and
any other dav related files that might come along. Greg/Joe?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_dav_svn
Posted by Ben Collins-Sussman <su...@collab.net>.
Joe Orton <jo...@btconnect.com> writes:
> > So my first question was originally: where is mod_dav_svn storing all
> > this stuff? On disk somewhere?
>
> Yup, mod_dav_svn persists activities using an extra 'activities'
> databases (just using APR's dbm interface) in the repostiry, see
> mod_dav_svn/activity.c.
Holy cow, there are some activity databases being dumped right into
the repository directory!
$ ls /www/svn/sussman-repo/
README* activities.dir activities.pag db/
Well, that explains it. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: mod_dav_svn
Posted by Joe Orton <jo...@btconnect.com>.
On Fri, Jul 06, 2001 at 05:13:29PM -0500, Ben Collins-Sussman wrote:
>
> I'm preparing to jump into ra_dav and mod_dav_svn. In particular, I'd
> like to get properties working over the wire. So I've spent all day
> re-reading the deltaV spec & examples, and Greg's quasi-outdated
> document on how deltaV maps to Subversion:
>
> http://www.webdav.org/deltav
>
> http://subversion.tigris.org/webdav-usage.html
>
> I know that Greg Stein isn't listening to email right now, due to more
> important engagements (:-)), but he may see some of these threads next
> week. Also, it's possible that Joe Orton may know a lot about this.
>
> First, I'd like verification that I understand what mod_dav_svn is
> really doing. It seems like a deltaV server has the job of creating
> lots of "temporary" URLs as way of continually building up state with
> the client. (Since HTTP is a stateless protocol, I guess this is all
> it can do!)
Yeah, exactly.
> mod_dav_svn puts all these temporary URLs into the $svn namespace:
>
> $svn/act/URL/UUID activities (fs transactions in progress)
> PROPFIND, DELETE (abort), MERGE (commit)
>
> $svn/his/[node-id] versioned history resources
>
> $svn/ver/[node-id]/[path] versioned resources -- immutable!
> PROPFIND, GET, REPORT (only read-only ops)
>
> $svn/wrk/[activity]/[path] working resources (being edited)
>
> $svn/blin baseline resources (not done) -- svn revisions?
> $svn/bsel
> $svn/bhis
>
>
> So my first question was originally: where is mod_dav_svn storing all
> this stuff? On disk somewhere?
Yup, mod_dav_svn persists activities using an extra 'activities'
databases (just using APR's dbm interface) in the repostiry, see
mod_dav_svn/activity.c.
joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org