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
(troycurti...@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
