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

Re: feature suggestion: adressing the repo relative to working copy url

From: Harald Kirsch <harald.kirsch_at_raytion.com>
Date: Wed, 22 Feb 2017 15:12:55 +0100

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:


  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.

Received on 2017-02-22 15:13:31 CET

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