On Mon, Oct 18, 2004 at 01:10:54PM -0500, kfogel@collab.net wrote:
> 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.)
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.
> 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.
Actually this is what you said in the past (from msgid
<858ydd5aub.fsf@newton.ch.collab.net> which can be found at
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=72323 )
> With this enhancement, anytime someone sets a property whose name
> contains special characters, we transform it into
> "svn:quoted-propname:<quoted-str>" for transport. In the actual
> working copy, and in the repository, it does not need the quoting,
> because our storage formats there can handle the real names. However,
> if an older repository happens to keep the quoting, that's okay! Old
> clients will simply fail to unquote it; new clients will correctly
> unquote it. No one will crash, and all information will be preserved
> in one of two possible forms, until eventually everyone is upgraded."
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.
> Grrrr :-).
> Why don't you wait to see the proposal and then talk about it?
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.
> 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 resolved the major bug. We no longer error on them. The bug is no
relegated to a much smaller minority of our users. See below for more
discussion on discouraging colons...
> 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.
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.
> 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.
Ohh come on. I spent several days working through this issue to try and
fix this issue and allow everything we allow currently. This is even
more unfair than above. I've never said it was okay. I don't like it.
But it's reality. I've never once advocated that we disallow colons as
the solution. Rather I've advocated that the solution wait till 2.0.
In the meantime we educate users as to the consequences of using colons
in property names. If the consequences aren't an issue for them then by
all means they should use them if they want.
Discourage != Disallow
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
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:54:18 2004