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:
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?
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
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
Looking to bounce ideas off another brain.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:33 2006