Peter N. Lundblad wrote:
> On Sat, 15 Jan 2005, Julian Foad wrote:
>>Peter N. Lundblad wrote:
>>>On Sat, 15 Jan 2005, Julian Foad wrote:
>>>>An advantage of being strict is that it leaves room for us to extend the syntax
>>>>in future by assigning meanings to paths that are currently non-canonical. For
>>>>example, we might one day want to assign a meaning to the double-slash, as in
>>>>current discussions about svn:external. If we allow that now as being just a
>>>>sloppy equivalent of a single slash, then we shut that door.
>>>
>>>This doesn't work, since the command line client canonicalizes its
>>>arguments.
>>
>>This does work, since the client software that would talk this extended
>>protocol would not be today's client. I'm talking about future extensions to
>>the client-server protocol which would involve modifying both the client and
>>the server.
>
> I think we'll want to choose some syntax that doesn't get destroyed by
> canonicalization (according to the current rules).
Syntax for the extended client-server protocol? Well, what we will want to
choose depends on what options we have then, which depends on what options we
leave open now. If we decide to enforce the protocol strictly now, I don't see
why we would then want to choose some syntax that doesn't get destroyed by
canonicalization.
> Also, we have a release
> version whihc would break in this case (referring to the svnserve fixes in
> 1.1.2).
What would break in what case? And is your example (presumably a 1.1.2 client
or server against a 2.x other end) likely to work at all anyway?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 16 17:23:44 2005