You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2020/03/27 23:16:58 UTC

Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)

Anton Shepelev wrote on Fri, 27 Mar 2020 01:39 +0300:
> Daniel Shahaf:
> 
> > Yes, this feature won't happen unless someone invests time in
> > making it happen -- but let's not discourage people from
> > discussing feature ideas even if they may not personally have
> > time to implement them. Discussions are just as useful a
> > contribution as patches.  
> 
> It is true that I was not prepared to implement this feature myself
> when I proposed it. Not having any knowledge of bash or Python, I
> would have to use SVN from C, which will take me considerable
> time. I am only learing SVN and giving my feedback about what I
> think are obvious inefficiencies of its user interface.
> 

Your feedback is very welcome. :-)

> I had already written about an extension of the caret syntax
> to take the current working directory into account, so that, being
> in svn/trunk/project/xml/ , one does not have to type
> 
>   svn cp ^/trunk/project/xml/1.xml ^/trunk/project/xml/2.xml
> 
> but can simply say:
> 
>   svn cp ~~/1.xml ~~/2.xml or
>   svn cp --remote 1.xml 2.xml
> 
> or something else to the same effect, so as not to repeat the paths
> from the repository root.
> 

I don't see where you wrote on this before, but in any case, this
sounds quite reasonable.  How about assigning it the syntax
«^./» (caret, dot, slash)?  That way we only have one "special" leading
character to worry about.

I expect this would be fairly easy to add, but haven't reviewed the code.

> I use SVN at work, so what I ask here is a personal and egoistical
> request to make my professional life better, but I hope that other
> users find the proposal convenient too. In return, I am contributing
> to other free and open-source projects, but not, currently, to SVN.
> 

I do this too. :)

Cheers,

Daniel

Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Anton Shepelev wrote on Sat, 28 Mar 2020 00:41 +00:00:
> Daniel Shahaf:
> > Tilde is also special to some shells, at least in the sh/csh
> > «~username» syntax and in zsh's «foo~bar» syntax (also part of
> > EXTENDED_GLOB);
> 
> That is why I proposed a double `~' -- not perfect, of course, but
> I think none of the major shells will expand it. Of course, if I
> were designing it from scratch I should try to pick a single ASCII
> character that none of the common shells treat as special. I am not
> even sure that such a character exists, does it?
> 

Period, comma, colon, underscore, plus, opening curly brace, forward
slash, closing square bracket(?), and multi-character sequences of
these.

> > An --option sounds a little too specialized to me.  Also, it's a
> > form of action at a distance (the positional arguments and the
> > --option's presence would be coupled), whereas the ^/ syntax is
> > self-contained.
> 
> Also true, but depends on one's viewpoint. I viewed
> `svn cp --remote' as a command acting upon the remote repository
> and `svn cp' as a command acting upon the working directory. In
> other words -- as a remote and a local command: two different
> commands with different interpretation of their arguments. Although
> this view is factally wrong,

Yeah, Subversion's convention is the other way around: arguments are
interpreted as URLs iff they look like URLs.  This is true throughout
the CLI as well as in the API (e.g., svn_client_copy_source_t::path,
despite its name).

> it helps me understand SVN better, because local operations and
> sever-side operations are in my opinion very different, even though
> they fall into the same categories of copy, delete, move, &c. They are
> like different implementations of the same interface, but I divagate.

They _are_ different implementations of the same interface…

But anyway, if you want a command that takes local filenames and copies
remote files, couldn't you just write one?  Using the URL flavours of
«svn cp» is racy (they won't throw out-of-date errors if something
changed between BASE and HEAD), but there are two sound alternatives:

1. This:

    #!/bin/sh
    svn cp -- "$1" "$2"
    svn ci -- "$2"
    svn up -r0 -- "$2"

2. «svnmucc -r».

Cheers,

Daniel

Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)

Posted by Anton Shepelev <an...@gmail.com>.
Daniel Shahaf:

> Here are our notes about this from back when the ^/ syntax was
> added:
> 
> http://svn.apache.org/viewvc/subversion/trunk/notes/cli-repo-root-relative-support.txt?view=markup#l42

It takes care of cmd.exe, so ^^/ on Windows was a deliberate
tradeoff on your part.

> Tilde is also special to some shells, at least in the sh/csh
> «~username» syntax and in zsh's «foo~bar» syntax (also part of
> EXTENDED_GLOB);

That is why I proposed a double `~' -- not perfect, of course, but
I think none of the major shells will expand it. Of course, if I
were designing it from scratch I should try to pick a single ASCII
character that none of the common shells treat as special. I am not
even sure that such a character exists, does it?

> and more generally, there's the consistency
> aspect, as you mention.  That matters, for example, for scripts
> that want to escape arbitrary local paths when calling svn.
> Today, the rule is "Append an '@', and if it starts with a
> caret-slash then prepend './'."; it would be nice not to break
> this.

True.

> An --option sounds a little too specialized to me.  Also, it's a
> form of action at a distance (the positional arguments and the
> --option's presence would be coupled), whereas the ^/ syntax is
> self-contained.

Also true, but depends on one's viewpoint. I viewed
`svn cp --remote' as a command acting upon the remote repository
and `svn cp' as a command acting upon the working directory. In
other words -- as a remote and a local command: two different
commands with different interpretation of their arguments. Although
this view is factally wrong, it helps me understand SVN better,
because local operations and sever-side operations are in my
opinion very different, even though they fall into the same
categories of copy, delete, move, &c. They are like different
implementations of the same interface, but I divagate.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]


Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Anton Shepelev wrote on Fri, 27 Mar 2020 23:40 +00:00:
> Daniel Shahaf:
> > but in any case, this sounds quite reasonable.  How about
> > assigning it the syntax «^./» (caret, dot, slash)?  That way we
> > only have one "special" leading character to worry about.
> 
> That ^ character must be escaped in Windows, so I don't really like
> it. My personal (and uneducated) preference of an inexperienced
> user is to activate CWD URL mode in a cleaner way: either by an
> option (quite possible, because SVN commands may share options), or
> via a simpler and shorter syntax than (on Windows) ^^./ . I will,
> however, be only happy if the caret version is implemented. It is,
> after all, consistent with the current usage.
> 
> I think other users of SVN via commadline (instead of the various
> GUI plugins) should give their opinions and help the maintaners
> make the correct decision.

Here are our notes about this from back when the ^/ syntax was added:

http://svn.apache.org/viewvc/subversion/trunk/notes/cli-repo-root-relative-support.txt?view=markup#l42

There must have been dev@ threads too, around the time that document
was written.

Tilde is also special to some shells, at least in the sh/csh «~username»
syntax and in zsh's «foo~bar» syntax (also part of EXTENDED_GLOB); and
more generally, there's the consistency aspect, as you mention.  That
matters, for example, for scripts that want to escape arbitrary local
paths when calling svn. Today, the rule is "Append an '@', and if it
starts with a caret-slash then prepend './'."; it would be nice not to
break this.

An --option sounds a little too specialized to me.  Also, it's a form of
action at a distance (the positional arguments and the --option's
presence would be coupled), whereas the ^/ syntax is self-contained.

Cheers,

Daniel

Re: Adding a shorthand URL syntax to cwd's URL (was: Re: Automatically supply the origin URL in svn merge)

Posted by Anton Shepelev <an...@gmail.com>.
Daniel Shahaf:

> > I had already written about an extension of the caret syntax
> > to take the current working directory into account, so that,
> > being in svn/trunk/project/xml/ , one does not have to type
> > 
> >   svn cp ^/trunk/project/xml/1.xml ^/trunk/project/xml/2.xml
> > 
> > but can simply say:
> > 
> >   svn cp ~~/1.xml ~~/2.xml or
> >   svn cp --remote 1.xml 2.xml
> > 
> > or something else to the same effect, so as not to repeat the
> > paths from the repository root.
> > 
> 
> I don't see where you wrote on this before,

Not preserved in Gmane, but it does not matter.

> but in any case, this sounds quite reasonable.  How about
> assigning it the syntax «^./» (caret, dot, slash)?  That way we
> only have one "special" leading character to worry about.

That ^ character must be escaped in Windows, so I don't really like
it. My personal (and uneducated) preference of an inexperienced
user is to activate CWD URL mode in a cleaner way: either by an
option (quite possible, because SVN commands may share options), or
via a simpler and shorter syntax than (on Windows) ^^./ . I will,
however, be only happy if the caret version is implemented. It is,
after all, consistent with the current usage.

I think other users of SVN via commadline (instead of the various
GUI plugins) should give their opinions and help the maintaners
make the correct decision.

-- 
()  ascii ribbon campaign - against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]