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

Re: DAV props -- how to proceed?

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-07-07 02:09:35 CEST

Joe Orton <jorton@btconnect.com> writes:

> On Fri, Jul 06, 2001 at 05:40:39PM -0500, Ben Collins-Sussman wrote:
> > Ben Collins-Sussman <sussman@collab.net> writes:
> >
> > > * Assume we want to hide them. Fine. Then they'll be stored as
> > > secret "wc props". But that means *every* RA layer needs to
> > > filter them out when reading the repository (so they can be stored
> > > differently on the client side.) Isn't this icky?
> >
> > Of course, another possibility is that we could make libsvn_wc
> > automatically filter live vs. dead props, and store them in different
> > places. But that's also kinda icky.
>
> Ah, I was going to avoid this issue completely*, and just map SVN
> user-supplied properties (from 'propset' or whatever) into (dead)
> properties on the DAV server in the 'SVN:custom' namespace. Then, ra_dav
> ignores all live and dead properties when fetching from the server
> except those in 'SVN:custom' and the other ones it knows about.

Well, that's certainly avoiding the issue! Still, if you can get all
user props moving both ways over the network, we'll love you. The
problem can be decided upon later.

What's going on here is that subversion filesystem just provides
"properties" is the most general sense. And now our WebDAV layer is
slowly creeping... creeping... creating distinct categories of
properties that all the rest of subversion has to deal with. I want
to stop implicit Policy-Creep, and instead *decide* on a good policy.

But please implement now. We'll settle policy next week. :-)

---------------------------------------------------------------------
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

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