On 10/05/2012 05:48 PM, Ben Reser wrote:
> On Fri, Oct 5, 2012 at 7:12 AM, C. Michael Pilato <cmpilato_at_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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-10-09 18:40:29 CEST