Ben Reser <ben@reser.org> writes:
> We've been down this road before. I'll be so bold to say that you're
> wasting your time and that I'm probably going to -1 (veto) any proposal
> you have. Here's why...
Then you're going to get a vote on that veto, if it comes to that :-).
(But you saw when I filed the issue... Perhaps you were just waiting
until you saw some action, which is understandable.)
> First and foremost this problem is the greatest for non-svn client
> implementations (i.e. DAV clients). These clients may be using XML
> parsers that enforce the XML namespace recommendations. This is
> unfortunate but understandable.
Yep, I know.
> Any method of fixing this requires encoding. Because property names are
> passed as XML elements there is no way to encode the data such that a
> valid XML parser will automatically decode it for us. This means that
> we must encode our data before generating the XML and then decode it in
> the client after the XML parser is done.
Right.
> Let's consider that we have 3 classes of clients we need to support with
> this change:
>
> * Old SVN clients that don't know about encoding of property names.
> * New SVN clients thta do know about encoding of property names.
> * DAV clients that know nothing about SVN.
Right.
> Currently, we have no way of separating a SVN client from a generic DAV
> client. In order to fix the DAV clients that dislike our XML we'd need
> to be sure to encode for them. However, if we encode properties for
> them we'd also be encoding for the old SVN clients that don't know
> anything about encoding of properties.
Right.
> In the past you've said that would be okay, they'd just get a property
> name that is different. But this is a compatability breakage. If
> talking to a 1.2 SVN DAV server makes svk:foo show up as some other name
> then existing SVK clients will break due to not seeing their property
> names. This would force all SVK users to upgrade to newer versions of
> SVK (or use a newer version of the bindings that know about the
> encoding) because the server was upgraded.
No, in the past I've said (or meant to say) that this fix needs to be
deployed using compatibility stages, and that it's important to roll
out the first stage -- the ability to decode these encodings -- as
soon as possible.
> As a result you can't fix the encoding problem for the only people it is
> creating a problem for (a small minority at that), the DAV clients.
> Without breaking our compatability with old SVN clients (a much larger
> group).
Grrrr :-).
Why don't you wait to see the proposal and then talk about it?
> Given that very few people have run into this issue. I think we have
> much more important things to worry about than this. Until 2.0 I think
> our only course of action is to discourage people from using colons in
> property names. Once 2.0 comes along we can break client
> interoperability and start encoding property names as you suggest.
Simply discouraging use of colons in property names is unacceptable to
me. Colons are the first and most obvious character people think of
when they need a namespace-ish separator. It was the first choice for
svk, it was the first choice for cvs2svn, and it would be the first
choice for anyone else. They're just following the lead suggested by
Subversion itself with our "svn:" properties.
Subversion properties were explicitly meant to allow colons since Day
One. This policy has never changed. A transport layer bug does not
constitute a change of policy, and a certain (minimal) degree of
compatibility pain may even be tolerable to fix such a major bug.
I am working on as thorough a proposal as I can come up with. It will
try to minimize compatibility problems. I think you're right that
there may still be some compatibility problems, but then it will just
be a question of which bug is worse.
And the answer to that question is *not* automatically "Compatibility
is always more important than any loss of functionality". This bug is
a loss of functionality, functionality which is quite user-visible and
which was documented to be in Subversion all along. We have a
cost/benefit analysis to make, and there is no automatically right
answer.
At bottom, I don't really understand why you think it's okay to not
allow colons in property names. Plenty of people want to do it, and
we always meant to support it.
-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 22:01:36 2004