[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnsync "207 Multi-Status" failure with http access method and property "svn:"

From: Kylo Ginsberg <kylo_at_kylo.net>
Date: Tue, 5 Jan 2010 09:19:50 -0800

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

Received on 2010-01-05 18:20:25 CET

This is an archived mail posted to the Subversion Dev mailing list.