Perhaps I'm not explaining well enough.
What I'm saying is all a consequence of my opinion that we should enforce
protocols strictly. If we don't, then in the medium to long term all the
different possible variations would add up and would all have to be supported.
Even if it takes no more code to permit than to reject the variations, the
definition of the protocol would become a mess and the possibility of extending
it would be markedly decreased.
When it comes to discussing whether to _increase_ this enforcement, the
decision is more difficult because we do not want to break existing
implementations unnecessarily. So perhaps we should attempt a stage of
deprecation in which we emit some sort of warnings (how?) when clients are
behaving badly, and then after a while we should actually refuse to accept the
bad formatting.
In this case, Peter Lundblad has already changed the "svnserve" protocol
implementation* to canonicalise all incoming paths, and he didn't see any
objection so we implicitly approved this approach. However, if we change this
from "canonicalise paths" to "ensure paths are canonical", the work of
discovering where to put the code is not wasted.
As for the implementation quality of "is_canonical", it should be equivalent to
"canonicalize". It could just call "canonicalize" and see if the result is any
different.
So is there any reason not to make "svnserve" strict and make "is_canonical"
thorough? How would we have to stage the change to avoid breaking existing
implementations before they have a chance to be fixed?
- Julian
* r12063, r12084, issue #2119.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 16 18:33:04 2005