feature suggestion: adressing the repo relative to working copy url

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

feature suggestion: adressing the repo relative to working copy url

Harald Kirsch
Hi all,

as suggested by Johan, I dare to drop a feature suggestion onto this
mailing list.

In a multi project repository, ^/trunk and ^/branches do not usually
point to the trunk and branches of a project. Rather something like

   ^/somedir/someproject/branches

is needed.

Given a working copy of ^/somedir/someproject/trunk, it would be great
to address the repository relative to that URL. Say '%' would be the
shortcut, then I could

svn list %/../branches
svn copy . %/../branches/mycoolfeature
svn switch . %/../branches/mycoolfeature
svn merge %/../../trunk

Use of '..' seems to be forbidden in repository URLs, but some syntax
should be possible to address this. %% for %/.. and %%% for %/../.. is
one thing that springs to mind, surely others can come up with even
better suggestions.


Rationale:

The sequence of commands shown above motivated me to suggest this
feature. Branching and merging would get much easier for multi-project
repositories, where ^ does not easily lead to trunk and branches.


Alternative Idea:

If trunk/tags/versions/branches where not just conventions, an
alternative would be to have a notation point to the "root of the
project", i.e. the parent of trunk and branches. But I would not know
how to sanely define it for working copies that have neither of
trunk/branches/tags/versions in their repository path's ancestry.

Harald
Reply | Threaded
Open this post in threaded view
|

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

Lorenz-2
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).


And why not use "^^/" to denote working copy root relative?
--

Lorenz

Reply | Threaded
Open this post in threaded view
|

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

Harald Kirsch


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
([hidden email]). 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
Reply | Threaded
Open this post in threaded view
|

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

Stefan Sperling
On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
> Am 21.02.2017 um 15:40 schrieb Lorenz:
> > 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.

In windows cmd.exe, ^ is a special character so there is already a need
to type ^^/ instead of ^/. This is a common pitfall for Windows users.
In cmd.exe ^^/ would need to be typed as ^^^^/ which is getting a bit long.

When ^/ was introduced, this problem was already known but accepted.
It is not easy to find a syntax which does not overlap with something
already used by various shells on various operating systems.

> 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.

Note that several relative URL notations were already defined for the
svn:externals property. You might want to avoid overlap with these and
perhaps try to find something that looks sufficiently different.

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
Reply | Threaded
Open this post in threaded view
|

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

Lorenz-2
Stefan Sperling wrote:

>On Wed, Feb 22, 2017 at 03:12:55PM +0100, Harald Kirsch wrote:
>> Am 21.02.2017 um 15:40 schrieb Lorenz:
>> > 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.
>
>In windows cmd.exe, ^ is a special character so there is already a need
>to type ^^/ instead of ^/. This is a common pitfall for Windows users.
>In cmd.exe ^^/ would need to be typed as ^^^^/ which is getting a bit long.
>
>When ^/ was introduced, this problem was already known but accepted.
>It is not easy to find a syntax which does not overlap with something
>already used by various shells on various operating systems.

if you put the path in quotes you don't need to double up the ^.


>> 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.
>
>Note that several relative URL notations were already defined for the
>svn:externals property. You might want to avoid overlap with these and
>perhaps try to find something that looks sufficiently different.
>
>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

and so on

The only difference to the svn:externals syntax you need to keep in
mind is that on the command line you always need the ^ in front.


I think my proposal for using ^^/ as working copy root is not
absolutely neccessary, by the way.
You can always get there with the appropriate number of ../  8-)
--

Lorenz

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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,
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

> and so on
>
> The only difference to the svn:externals syntax you need to keep in
> mind is that on the command line you always need the ^ in front.
>
>
> I think my proposal for using ^^/ as working copy root is not
> absolutely neccessary, by the way.
> You can always get there with the appropriate number of ../  8-)

The working copy root is a fluid concept: sometimes people root their
wc's above or below the branch root.  It might be nice to have a syntax
that will mean "relative to the branch root"... that is, to have the
design specify a syntax that will mean "relative to the branch root"
when we invent a concept of "branch roots".

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

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

Lorenz-2
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,
>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
>[...]

the last is an independent idea for an additional feature, right?

'foo' would be a shortcut for a base URL?
I think, without some sort of indicator, it looks to much like a path.
I would prefer to mark a shortcut explicitly as such.
No idea how though, another prefix? Perhaps '^:shortcut/" would do?


But back to original topic: I could live with using '^./' as the
general prefix for "current working copy folder relative addressing".

so my 4 examples above would change to:

^./subpath subpath of the  current working copy folder
^./../ parent
^./../path sibling
^./../../ grand parent
--

Lorenz

Reply | Threaded
Open this post in threaded view
|

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

Branko Čibej
In reply to this post by Daniel Shahaf-2
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.

> 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. :)

-- Brane
Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
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. :-)
Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
In reply to this post by Lorenz-2
Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +0000:

> 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,
> >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
> >[...]
>
> the last is an independent idea for an additional feature, right?

Partly.

Implementation wise,, the "map of short names to URLs" needn't be
implemented at the same time as the other ideas; those _are_
independent.  However, at the UI level, both feature ideas touch on the
same '"URL" space', so at that level they aren't independent.

> 'foo' would be a shortcut for a base URL?
> I think, without some sort of indicator, it looks to much like a path.
> I would prefer to mark a shortcut explicitly as such.
> No idea how though, another prefix? Perhaps '^:shortcut/" would do?
>

Maybe. :-)

>
> But back to original topic: I could live with using '^./' as the
> general prefix for "current working copy folder relative addressing".
>
> so my 4 examples above would change to:
>
> ^./subpath subpath of the  current working copy folder
> ^./../ parent
> ^./../path sibling
> ^./../../ grand parent

Okay.  I see you changed ^../ to ^./../ .  What would ^../ mean then?

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

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

Lorenz-2
In reply to this post by Branko Čibej
Branko ?ibej wrote:

>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.
>[...]

hm, to what existing syntax would "^./subpath" be in conflict with?
--

Lorenz

Reply | Threaded
Open this post in threaded view
|

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

Lorenz-2
In reply to this post by Daniel Shahaf-2
Daniel Shahaf wrote:

>Lorenz wrote on Thu, Feb 23, 2017 at 07:33:54 +0000:
>[...]
>>
>> But back to original topic: I could live with using '^./' as the
>> general prefix for "current working copy folder relative addressing".
>>
>> so my 4 examples above would change to:
>>
>> ^./subpath subpath of the  current working copy folder
>> ^./../ parent
>> ^./../path sibling
>> ^./../../ grand parent
>
>Okay.  I see you changed ^../ to ^./../ .  What would ^../ mean then?

nothing 8-)

Only ^/... and ^./... would be allowed.
--

Lorenz