Ben Collins-Sussman wrote:
>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. :-)
>
+1, absolutely. I think it's the only sane thing to do.
I have one question, though: Why does mod_dav_svn use another dbm to
store the props, if we already use Berkeley DB? Wouldn't it be better to
just create a DB3 environment in .../dav, parallel to .../db?
I have no idea how these DAV-specific props work, but I understand their
number (and the number of activities) grows proportionally to the number
of live clients (and/or repository size?), so using a flat dbm file
doesn't scale well.
And since we're talking about property policy: in another message you
mentioned the commit timestamp property. This is clearly a property
users have to see (it's not ra-layer specific), but I think users
shouldn't be able to modify it. I think we need a new class of read-only
properties. I think these will always be properties that are generated
by the server. Commit timestamp is one, committer ID is another, also (I
think) the repository revisioin number that a file revision first
appears in (we're generating that, aren't we?) .
Brane
--
Brane �ibej
home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
ACM : <brane_at_acm.org> http://www.acm.org/
---------------------------------------------------------------------
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