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. :-)
Received on 2017-02-23 16:03:27 CET