On Tue, Jan 5, 2010 at 8:45 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Kylo Ginsberg wrote:
>> 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.
Ah, thanks, it's making more sense now. But are svn:xxx properties
handled via a different mechanism than other property namespaces? I
ask b/c experimentally I see that I can create or access a "foo:"
property via http just fine. So this problem is apparently entirely
restricted to the single case of an inadvertent "svn:" property?
> 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").
# svn ps "svn:property name" asdf foo.txt
svn: 'svn:property name' is not a valid Subversion property name
I wonder if the spot where this validation is done could validate the
above case also?
> 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.
If, as it appears, it's just "svn:" here, the pre-commit hook is pretty trivial.
> 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.
That all sounds pretty reasonable, but may be a heavyweight solution
given what (I now believe to be) the pretty limited scope of the
problem.
Thanks,
Kylo
Received on 2010-01-05 18:20:25 CET