On Fri, Aug 11, 2000 at 12:42:13PM -0400, Greg Hudson wrote:
> Greg Stein's new WebDAV usage document says:
> > Subversion uses a tree-based format to describe a change set against
> > the repository. This tree is constructed on the client side to
> > describe the change. It is then marshalled to the server,
> > reconstructed, and applied against the repository. However, WebDAV
> > uses a sequence of changes. As a result, we must map from the tree
> > form to a sequence of WebDAV requests, send them over the wire, then
> > reconstruct the tree form on the server for application to the
> > repository.
> I don't understand, even at a high level, how this is going to work.
> Is the server going to completely ignore the WebDAV-specified
> semantics of the sequence of requests, construct a tree, and then
> process them in a subversion-specified manner?
Insofar as I understand your question: yes, the server will reconstruct a
tree from the sequence of requests, then shove that tree into the "backend"
> Does this actually qualify as "using WebDAV?"
Of course. WebDAV is a protocol. That's it. We'll use that over the wire.
That is exactly what "using WebDAV" means :-)
> For that matter, WebDAV doesn't appear to have the concept of a
> sequence of requests, just individual requests. How do we delineate
> the beginning and end of a sequence? (And, as before, doesn't this
> break the WebDAV model a whole lot?)
An "activity" is the transactional unit. We will create an activity at the
beginning of a change set, issue a group of requests for that activity, then
merge the activity into the repository. In HTTP terms, the transaction is
bounded by the MKACTIVITY and MERGE methods. Everything between those two
methods will be associated with the activity.
I'm going to be working on the document tonite and tomorrow. Hopefully, that
will clear things up. If *not*, then I would *greatly* appreciate your
feedback. This is intended to be a design document, and if it fails to
explain how things will work... then I need to fix it.
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:06 2006