On Tue, Jan 5, 2010 at 8:45 AM, C. Michael Pilato <cmpil...@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
