Am 21.02.2017 um 15:40 schrieb Lorenz:
> Harald Kirsch wrote:
>> [about working copy relative URLs]
>
> This a purely client side path to URL transformation.
> So what is needed as a means to tell the client to use the URL
> associated with the given path.
>
> there is already the "^/" notation to tell the command line client
> that you what to start a URL beginning at the root of the repository
> your working copy was checked out from.
>
> As I see it, the client already interprets the leading "^" as "convert
> the following path to an URL".
>
> "^/" then translates to "repository root"
>
>
> So "^path" could be interpreted as a path relative to the current
> working copy folder (including sequences of "../" as needed).
Looking at the commit for the improvement that introduced the ^/
notation, it also contains the strict refusal to accept '..' in a path:
libsvn_subr/opt.c:
870827 julianfoad 2008-04-22 17:21:36 +0200 (Di, 22. Apr 2008)
_("URL '%s' contains a '..' element"),
I could not find a rationale for this, but it is likely a security
consideration. The patch was from Troy Curtis Jr
(troycurtisjr_at_gmail.com). It would be good to know the arguments, why
'..' is not allowed, before it is (re)introduced.
>
> And why not use "^^/" to denote working copy root relative?
>
Would work for me. But intuitively ^^/ seems to refer even higher up in
the directory hierarchy than ^/, but its not, so this notation might be
slightly misleading.
Alternative idea:
^./ -- repo URL for .
^../ -- its parent
^.../ -- its grand parent
In particular the .-Notation would not be the general case a/../b but
would only be allowed exactly as shown at the start of the URL.
Harald
Received on 2017-02-22 15:13:31 CET