On Mon, Jul 16, 2001 at 11:53:04AM -0500, Ben Collins-Sussman wrote:
> Joe Orton <email@example.com> writes:
> > > * I attempted to checkout again over DAV, and got no properties at all.
> > The patch I posted gets this working.
> Whoops, let me go find that post and try it out...
It's with subject "[PATCH] r/w dav props" I think.
> > 2) we only allow setting user properties through a specific namespace
> > e.g. "SVN:custom"
> Um, if you're talking about forcing either the user or the client
> libraries to auto-prepend this prefix, that's not acceptable.
Yes, right, when I say "only allow" I meant the *server* only handles
setting SVN properties which have this namespace.
> > Greg may prefer to do this properly, which would require some large
> > changes to mod_dav itself AFAICT.
> I'm probably getting really confused on this issue, but here are our
> immediate needs:
No, you're not confused, I was confused about (1) below but now I
understand it and agree with everything you say :)
> 1. All DAV, DeltaV, and mod_dav_svn-specific properties need to be
> stored in their own apr dbm table in the repository, not in the
> repository itself.
> 2. All regular, subversion user properties need to stored in the
> repository in un-mangled form, and generally need to appear
> un-mangled on both ends of the network. (If the network layer
> wants to mangle during transport, that's its own business.)
> So yes, I guess this means making some large changes to both ra_dav
> and mod_dav_svn.
[moving this down]
> (option A) If ra_dav wants to secretly prepend "SVN:" to all user
> props, and if mod_dav_svn wants to secretly remove them before
> storing them in the repository -- then great, that's fine. I guess
> secret prepending & removal would have to work in the other
> direction too.
(it's not really prepending, in DAV a property's namespace is separate
from its name, but yes)
> (option B) The two ends of the pipe need to distinguish between
> Subversion properties and DAV properties, since they'll be handled
> differently. It sounds like this is the "right" way to do things.
> So what should we do, Joe? Option A or option B?
Both :) The patch I posted does all the client-side stuff necessary, I
think. But to satisfy goal (1) above is a really big job.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:33 2006