On 10/05/2012 05:48 PM, Ben Reser wrote: > On Fri, Oct 5, 2012 at 7:12 AM, C. Michael Pilato <cmpil...@collab.net> wrote: >> That's right. Expat just doesn't care. Some other XML parser might. But >> then, I would expect that same parser would croak on any property name with >> a colon in it (besides "svn:", which we handle specially already). So all >> of TortoiseSVN's properties, cvs2svn's properties, etc. -- all that stops >> working. > > [snip] > >> I don't think so. I think that would be just a lovely instance of the >> perfect being the enemy of the good [enough]. If it becomes a real-world >> problem, our recourse is rather straightforward -- we continue our move away >> from the DAV standard and implement our own custom POST/REPORT handling. > > My memory is fuzzy on this and it's been 5-6 years but ISTR that the > problem was with people using auto versioning since the XML wouldn't > be valid. > > -1: On just doing this and hoping for the best. If it really is auto > versioning that breaks due to this, it is a supported feature of our > code set and not one that I suspect any of us test very often. If we > test auto versioning with the most commonly used configs and we have > no issues then I'd be +0.
Just some thoughts/comments in no particular order: - IIRC, autoversioning clients are broken in this respect anyway, and simply can't be fixed because Subversion's property storage namespace is flat and WebDAV's is all ns&name's. We could store autoversioning client-generated properties with URI-ish names (ns + "/" + uri_encode(name)) or something, but we've historically just silently dumped the namespaces for properties from those clients. Autoversioning clients also won't care about my svn:txn: properties because those only exist on transactions and revisions, which are resource types that autoversioning clients don't care about. (They focus on the directory trees.) - Last week I went ahead and started looking into revamping our propget/set DAV protocol so that this problem no longer exists for HTTPv2 clients. This is fairly trivial work, but also seems less useful overall. If a client is speaking HTTPv2, it's already doing Subversion-specific stuff and not strick DAV compliance, so it surely is capable of gracefully dealing with our current broken handling of colon-bearing properties. - Yesterday I started coding a more generic approach to colon-bearing properties. libsvn_ra_serf and mod_dav_svn now relay xmlns mappings of a dynamically generated prefix to a URI which is a child of a fixed "extensible xmlns URI". So a property such as "svn:config:foo" gets transmitted as "<svn0:foo>" (or "<svn1:foo>", or "<svn2:foo>" ...) with a prior declaration that the "svn0" prefix maps to the namespace "http://subversion.apache.org/xmlns/ext/svn:config";. So long as both ends of the wire know what's so special about that namespace URI (as they currently do with the "svn", "dav", and "custom" namespace URIs we employ), stuff seems to generally work. I'll toss this work onto a branch a bit later, because I've not done any extensive testing and I'm not convinced that doing so is the best use of my time. - I will revert my use of svn:txn:* for ephemeral txnprops, and will formally recommend to Paul that he switch to svn:config-* for his autoprops-sdc branch. At a minimum, those changes will not effect the existing WebDAV property support levels at all, and that's probably for the best at this phase of the release cycle. -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
