Ben Reser <ben@reser.org> writes:
> Well actually you didn't file the issue. I milestoned it to 2.0 and
> then didn't see you change it to 1.2 or I would have objected then.
> Probably happened with a bunch of other milestones and I read right past
> it.
Whups -- yes, I meant "milestoned".
> Old clients failing to unquote it as you state above is a failure of our
> compatability guarantees. We know there are popular programs using
> property names with colons in them.
>
> That said your proposal for adding the decoding scheme is fine if you
> work with the following time frame:
>
> 1.x clients gain the ability to decode the property names.
> 2.x servers encode the property names.
>
> That's fine. But it doesn't really fix the issue earlier which is what
> your stated goal is. It just helps with our compatability for 1.x
> clients with 2.x servers when we do fix this. Which may or may not
> matter in the future, depending on other changes. Not that I'd object
> to adding the decoding as early as possible to help offset that
> compatability issue.
>
> However, even if we add the decoding scheme now, the bug will not be
> closed until 2.0. So your 1.2 milestone is wrong.
It's only wrong if one accepts that it cannot be solved before 2.0,
which is what we're discussing.
(Note also that sometimes we put a multi-stage issue in the first
relevant milestone, with a note to bump to a later one when the first
stage is fixed, and so on. Not that that's what I intended here.)
> Because you haven't sent it and I can't see how you're going to
> fix the problem until 2.0 without breaking compatability in a completely
> unacceptable way. As a result I'd rather see you spend your time on
> more important things.
Fair enough -- I can't really argue with that answer :-).
> This is a really unfair response. I'm responding on the basis of that
> cost benefit analysis. Our clients are perfectly functional with
> coloned names currently. The only issue is with other DAV clients that
> enforce the XML namespace rules. This is unfortunate, but we already
> know other areas where we're not compatable with DAV clients fully.
> That said, I don't think DAV compatablity should ever come before SVN
> client compatability. If we have to break SVN clients for DAV clients
> to work that's not a tradeoff I'm willing to make.
Here's why I'm worried:
Aren't we also depending on Subversion's XML parser remaining loose
for the rest of the 1.x line, when in fact that would be hard for us
to guarantee that it remain that loose -- because it comes from an
external library that we might want to upgrade for other reasons?
Thus the issue is that even Subversion isn't safe for these properties
in the long term. That's why I think this issue is important now.
Sorry to have attributed to ignorance what can be adequately explained
by merely different priorities. I do realize that you don't like the
current situation either, didn't mean to imply otherwise.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 18 23:19:01 2004