I'm a bit confused about what characters we're disallowing in property
names, and about the reasons we're disallowing them.
My understanding was that we had a problem with ":" in a property
name, due to a WebDAV protocol problem. We all agreed this was a bug.
Ben Reser went to fix it one way, but ended up having to fix it
another way, see issue #1807 for details.
Now we're talking about "/" being disallowed in property names. Why
is it disallowed? I'm not saying there should be no limitations on
property names -- newlines and other control chars seem like a bad
idea, for example. But "/"? What's wrong with "/"?
If the issue is that a particular transport layer (DAV) makes it
difficult to allow certain otherwise-desirable chars, then we have a
bug in our transport layer, and should treat it as such. Now, maybe
we need to disallow those chars in propset for a while, until we fix
the bug. But we shouldn't be treating this as a permanent and
acceptable state of affairs. The property namespace is Subversion's;
the fact that we use XML or XML-based protocols is an implementation
detail that shouldn't be leaking out into userland.
Is there some more subtle issue here? Is it that we need to limit
these properties because DAV has its own idea of properties and we
want to remain compatible with DAV clients? If so, perhaps we should
be thinking of a compatibility strategy other than "Limit everyone to
whatever DAV can handle."
(Are there other chars we don't allow, and if so, why?)
-Karl
Ben Reser <ben@reser.org> writes:
> On Mon, Jul 19, 2004 at 05:00:33PM -0700, Michael Brouwer wrote:
> > Of course svk (or more precisely SVN:Mirror) uses / in property names
> > which isn't even allowed anymore in 1.1 (not sure if it worked prior to
> > 1.1 either). You can't use svn ps to modify or set a property with a /
> > in it, though setting it though the perl-swig bindings does work since
> > that's what SVN:Mirror does.
>
> Never were allowed. clkao is changing that hopefully in some future
> version of SVN::Mirror and then in 1.2 I intend to fix our API to
> totally disallow this "bug".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 21 18:16:34 2004