On Tue, Oct 9, 2012 at 12:39 PM, C. Michael Pilato <cmpilato_at_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 <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.
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 <cmpilato_at_collab.net>
> CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-10-09 20:43:20 CEST