[jira] [Comment Edited] (SVN-4006) Make "svn switch" say "Switched" instead of "Updated" or "At"

["Ivan Zhakov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SVN-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14930879#comment-14930879 ] 

Ivan Zhakov edited comment on SVN-4006 at 10/18/15 12:54 PM:
-------------------------------------------------------------

Note that we already have an optimized query to determine if a tree contains  switched paths. (This query is used for 'svnversion' and maybe also for 'svn merge')



was (Author: rhuijben):
{noformat:nopanel=true}
Note that we already have an optimized query to determine if a tree contains 
switched paths. (This query is used for 'svnversion' and maybe also for 'svn 
merge')
{noformat}


> Make "svn switch" say "Switched" instead of "Updated" or "At"
> -------------------------------------------------------------
>
>                 Key: SVN-4006
>                 URL: https://issues.apache.org/jira/browse/SVN-4006
>             Project: Subversion
>          Issue Type: Improvement
>          Components: cmdline client
>    Affects Versions: all
>            Reporter: Julian Foad
>             Fix For: unscheduled
>
>
> From the dev@ email thread 'Make "svn switch" say "Switched" instead of "Updated" or "At"', on 2011-09-05 <http://svn.haxx.se/dev/archive-2011-09/0084.shtml>.
> The final message from "svn switch" is exactly the same as for "svn update" -- either:
> {noformat}
> $ svn sw file://.../repo/X wc
> A    wc/foo
> Updated to revision 4.
> {noformat}
> or:
> {noformat}
> $ svn sw file://.../repo/X wc
> At revision 4.
> {noformat}
> depending on whether there was a change of content.  To the user who requested a switch, I think both of those are a bit cryptic.  We can make the message much more reassuring:
>   * If the new URL is different from the old one, as is usually expected, then say "Switched" (instead of, or perhaps as well as "Updated" or "At").
>   * When we say "Switched", say the target URL as well as the revision.
>   * If the new URL is the same as the old one then the operation degenerates to an update, so we could say "Updated" or "At" depending on whether there was a change of content, just as we do at present.  And maybe warn the user that the WC is already at that URL, because that's usually unexpected in interactive use.
> So, maybe like this:
> {noformat}
> $ svn sw ...  # URL change, content change
> [...]
> Switched to file://.../repo/X, revision 4.
> $ svn sw ...  # URL change, no content change
> Switched to file://.../repo/X, revision 4.
> $ svn sw ...  # No URL change, content change
> [...]
> Updated to revision 4.
> $ svn sw ...  # No URL change, no content change
> At revision 4.
> {noformat}
> Or, to preserve the distinction of whether there's a content change, to be more consistent, and also to be more vocal when there's no URL change:
> {noformat}
> $ svn sw ...  # URL change, content change
> Switched to URL file://.../repo/X.
> At revision 4.
> $ svn sw ...  # URL change, no content change
> Switched to URL file://.../repo/X.
> Updated to revision 4.
> $ svn sw ...  # No URL change, content change
> [...]
> Already at URL file://.../repo/X.
> Updated to revision 4.
> $ svn sw ...  # No URL change, no content change
> Already at URL file://.../repo/X.
> At revision 4.
> {noformat}
> I don't know how important backward compatibility is, but that preserves a final backward-compatible line, as well as being clear and unambiguous.  If we think one-line output is more important than this kind of backward compatibility, simply concatenate the two messages on one line.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)