+1 here too, Ben.
Not sure I'd go so far as to say that how the network layer works
needs to be *invisible* to the user, but the network layer does need
to avoid interfering with domains that one reasonably expects to be
isolated from networking code. Subversion properties are one such
domain.
-K
Branko Čibej <brane@xbc.nu> writes:
> 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
---------------------------------------------------------------------
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