On Tue, Jul 30, 2002 at 06:18:44AM -0500, Ben Collins-Sussman wrote:
>...
> > > ra_dav->get_dir() is simply trying to figure out if the resource has
> > > any user-defined props, and now it can't tell them apart from
> > > svn-specific liveprops anymore. :-(
>...
> The confusion here is that you and I have different definition of
> "user" properties. Your definition seems to be: "any property name
> set by the user that doesn't start with svn:". My definition is "any
> property stored in the repository."
>
> ra->get_dir() is trying to answer the question: "does this resource
> have props attached to it in the repository?" So it needs to notice
> properties named "foo" and "svn:eol-style", but it needs to *ignore*
> properties like "svn:baseline-relative-path". There's doesn't seem to
> be a way to do that.
FYI (dev list):
The Chicago guys and I had a phone conversation this morning, and we covered
this topic. Specifically, we are going to marshal properties over the wire
as one of three types of properties (discrimated by the XML namespace URI):
1) svn-defined properties (not in repository; "entry" props)
2) user-defined properties (svn propset ...)
3) dav-defined properties (mod_dav_svn and libsvn_ra_dav)
So svn:baseline-relative-path will move into type (3). We are also going to
change the URIs that we use within the XML documents/fragments.
Specifically, we're going to switch to http URLs (rather than "svn:" and
similar). The URI community has had discussions on whether "foo:" is a legal
URI, and we still have the issue that "svn" would need to be registered as a
scheme (where "registration" means an Internet-Draft and/or RFC). We can
simply avoid the whole question by using URLs when marshalling content
to/from XML.
To change the URIs, we're going to update the client to recognize both. Let
that client filter out into the user base, and then upgrade the server
sometime in the future to generate the new URIs.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 30 23:08:00 2002