[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

locking: serious RA interoperability problems.

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2005-02-14 17:51:25 CET

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

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

      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

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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.