[dropping users@ -- we're well into dev-land here.]
Kylo Ginsberg wrote:
> So one bug/enhancement here is to improve client reporting when it
> encounters a 207.
>
> But back to the root of my original problem: I can create a "svn:"
> property via the svn access method without any errors which then
> results in errors when accessed via the http access method. That
> seems like a bug, yes? But is the problem that the svn access method
> *allows* this bogus property, or that http chokes on it?
That http chokes on it is a result of fact that we're trying to use WebDAV
for these property interactions. PROPFINDs have a fixed response format
which dictates that the property names be XML tags. That adds a whole layer
of requirements for those names that technically Subversion itself doesn't
itself need.
SIDEBAR: What happens if you set a property with a space in its name? Does
the XML from mod_dav_svn have a tag like <S:property name>? If that doesn't
fail, it would do worse: it could set a client-side property that doesn't
actually exist in the repository "(property" instead of "property name").
Anyway, it doesn't bother me that some RA layers allow things that others
don't. I don't think the lowest common denominator is always a worthwhile
goal, especially since most folks don't deploy Subversion over both svnserve
and mod_dav_svn. We should document the differences, of course, and perhaps
we can recommend a pre-commit hook script that is smart enough to check for
all these kinds of potential gotchas.
So I'd say it's a problem with http choking, and I say further that to the
degree that we use WebDAV, we can expect this to keep happening. But
perhaps the solution here is to ditch the PROPFINDs, though, and add a new
custom REPORT request that's smart enough to deal with these issues. I
mean, simply by moving the property names into CDATA, we'd gain alot more
flexibility than we have today.
The server can still support the PROPFINDs, of course, for compatability
with older clients. Such compatibility means that either those PROPFINDs
need to behave exactly as they do today, or they need to fail gracefully
otherwise. But yes, they do need to fail -- we don't want a client getting
incomplete data and thinking it's complete.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-01-05 17:46:36 CET