OK, so I've had a night to sleep on this, and I now have a strong
opinion on how to deal with DAV props versus 'regular' props.
First, I believe there is fundamental difference between these
categories. 'Regular' props are the ones the user cares about and
expects to see and change. Regular props are versioned along with
file text. Meanwhile, DAV props are necessary bookkeeping for a
certain network layer. They are *not* versioned, and the user isn't
interested in them -- they're an implementation detail of one
particular RA module.
I realize now that this situation has already come up before. ra_dav
had to store bookkeeping properties on the client-side in order to
function. Our final solution was *not* to treat these props as normal
ones, and instead store them in a secret area of the SVN/
administrative dir (and provide the RA layer special get/set routines
for them.) This prevents the properties from being versioned & stored
in the repository, and prevents the user from knowing they even exist.
This was a solution that everybody was satisfied with. It also
implied a general principle:
RA implementation details should *not* be visible to the user. It
should be impossible (from the user's point of view) to discern how
a working copy is accessing a repository.
I believe now that this principle can be extended to the other half of
the situation we're now in. I say "other half", because now we see
that the DAV layer wants to store bookkeeping props on the subversion
*server*.
It's very easy to say: "hey, libsvn_fs has props, WebDAV has props, so
let's line them up, and use namespaces to sort them out." But this
violates the principle above. Suddenly, one RA module's
implementation details are exposed to the whole world. They're
sitting in the repository -- and now a burden has been placed on
*every* reader of the repository to either filter them out or wrongly
expose them to the user. And we're not just talking about other RA
modules; we're talking about all future applications that will use
libsvn_fs! This is totally unacceptable, IMHO.
But notice that Greg Stein has already solved a similar problem.
mod_dav_svn needs to track temporary URLs that that represent fs
transactions -- and it's doing this by dumping tables to a private dbm
file in the repository dir (using APR dbm routines.)
Therefore, I say that all of the server-generated "DAV:" props be
stored in the same way -- in a private dbm file. It keeps the
repository pristine, and is perfectly consistent with the way we solve
this problem on the client-side.
Feedback? Let me hear some +1's. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:33 2006