On Tue, Oct 9, 2012 at 12:39 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > 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.
Done r1396184. -- Paul T. Burba CollabNet, Inc. -- www.collab.net -- Enterprise Cloud Development Skype: ptburba > 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
