Branko Čibej wrote on Thu, Feb 23, 2017 at 13:47:12 +0100: > On 22.02.2017 17:42, Daniel Shahaf wrote: > > Lorenz wrote on Wed, Feb 22, 2017 at 15:28:19 +0000: > >> Stefan Sperling wrote: > >> >From 'svn help ps': > >>> The URL may be a full URL or a relative URL starting with one of: > >>> ../ to the parent directory of the extracted external > >>> ^/ to the repository root > >>> / to the server root > >>> // to the URL scheme > >>> ^/../ to a sibling repository beneath the same SVNParentPath > >>> location > >> I am aware of the svn:externals syntax, but in light of the fact that > >> ^/ was alread adopted, I thought it best to stick with the ^ > >> > >> If the cmomand line client accepts the ^ as the "translate the > >> following path to an URL" marker, then anything after it could be > >> interpreted as a normal path. > >> > >> ^/ repo root relative > >> ^/../name sibling repo > >> > >> ^subpath subpath of the current working copy folder > >> ^../ parent > >> ^../path sibling > >> ^../../ grand parent > > If the first of these four were changed to require a ./ path component, > > ... then it would not be backward compatible with existing syntax. >
My suggestion doesn't change the meaning of the released ^/foo syntax, only of the ^foo/ syntax [where "foo" doesn't begin with a slash] in Lorenz's proposal. Thus, it's backwards compatible. > > we could repurpose the ^foo/ syntax to something else: > > > > ^./subpath subpath relative to URL of cwd > > ^foo/ as defined by a --config-option=config:short-urls:foo=bar > > config option > > Ah, a config option to enable mutually incompatible semantics to > short-url syntax! > > I'm assuming you're volunteering to personally solve any confusion that > causes on the users@ list and beyond, for the forseeable future. :) I'm personally volunteering to fly over to your place and explain on a whiteboard how this is backwards compatible. :-)
