You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Ivan Zhakov (JIRA)" <ji...@apache.org> on 2015/10/18 14:53:05 UTC
[jira] [Updated] (SVN-4006) Make "svn switch" say "Switched"
instead of "Updated" or "At"
[ https://issues.apache.org/jira/browse/SVN-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Ivan Zhakov updated SVN-4006:
-----------------------------
Description:
>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.
was:
{noformat:nopanel=true}
>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:
$ svn sw file://.../repo/X wc
A wc/foo
Updated to revision 4.
or:
$ svn sw file://.../repo/X wc
At revision 4.
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:
$ 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.
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:
$ 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.
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.
{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)