[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Enforce canonical paths in client-server protocol? [was: svn commit: r12738 - in trunk/subversion: include libsvn_subr mod_dav_svn]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-16 17:22:29 CET

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
>>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

> 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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.