Hey folks, remember the discussion I brought up last month, regarding
the fact that mod_dav pushes extra XML junk to mod_dav_svn when it hands
down a lock object? There was some chat between me, gstein, and
Julian Reschke, and we came up with a scheme to deal with this.
But after some discussion with kfogel and cmpilato, it seems that the
problem is much nastier than I suspected. I want to describe the
problem (and potential solution) here. Developers, please read and
comment on this. It's about general RA and locking design... no
DAV-specific knowledge is required.
The Goal:
We want the new locking feature to be well-designed in its own right,
but we also want it to be interoperable with generic DAV clients, so
that autoversioning really gets finished. Up till now, we've been
able to balance this tension pretty well. We're close to being done.
The Problem:
The DAV spec requires the server to preserve *all* information
surrounding a DAV-lock's "author" field, which we map to
svn_lock_t->comment. So by default, mod_dav passes this field to
mod_dav_svn wrapped up in the original <D:author> xml tag, and
mod_dav_svn is expected to save it and retrieve it verbatim, as a big
opaque block. The theory is that a DAV client like MSWord might
create extra attributes on the tag, or put all sorts of custom XML
data within the tag's cdata. mod_dav must blindly preserve all that,
with no attempt at interpretation.
So, there are actually *two* problems right now.
1. mod_dav always passes an incoming lock structure to mod_dav_svn
with the lock->comment field "wrapped" in XML. As a result, when
other RA layers (or svnlook/svnserve) examine the repository, they
see this extra junk in the lock structure, and even marshall the
noise back to the client.
(This was the original problem we pointed out last month.)
2. When a non-dav RA layer stores a lock structure in the repository,
the lock->comment field has no XML wrapping. Later on, mod_dav
reads the lock and sends it to some DAV client (svn or otherwise),
but the HTTP response is invalid, because there's no XML wrapping
around the field! mod_dav doesn't realize that it needs to add XML
wrapping.
So this is a case of an RA layer having "special needs" that poke into
the general svn design, and causes it to be non-interoperable with
other RA layers.
Proposed Solution:
The Chicago office came up with several ideas, but this one seemed to
be the least nasty and intrusive.
A. Add a new boolean field to the svn_lock_t structure. It would be
named "xml-packaged-comment", or something similar. It defaults to
0, and if set, it means that lock->comment is packaged in XML.
B. When writing locks to the repository:
1. svnserve (and other non-dav writers) continue normally,
creating repository locks with the new boolean==0. They
effectively ignore the new field.
2. mod_dav_svn notices whether the incoming lock was created by
an svn client or a generic DAV client. (There are many ways
to do this, and they've already been discussed elsewhere.)
If the lock comes from an svn client, the XML-packaging is
stripped and the lock is written with the boolean==0. if the
lock comes from a generic DAV client, the packaging is
preserved and the lock is written with the boolean==1.
C. When reading locks from the repository:
1. svnserve (and other non-dav readers) continue to read locks
normally, ignoring the new boolean field. If extra XML junk
ends up being marshalled back to the client, that simply
means the lock was created by a generic DAV client. No big
deal.
2. mod_dav_svn notices the boolean field when reading. If 0, it
re-adds the necessary XML wrapper. If 1, it sends the data
as-is.
I'll let this idea sit out there for a day or two, so we can get some
nice feedback. But this really isn't something we can punt. I used
to think that this problem was a mere annoyance: "ew, extra dav junk
is visible through svnserve." But it's a lot worse than that. It's
now the case that svnserve is creating locks in the repository that
ra_dav *cannot* fetch and parse!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 14 17:53:36 2005