[
https://issues.apache.org/jira/browse/SVN-4006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14930878#comment-14930878
]
Ivan Zhakov edited comment on SVN-4006 at 10/18/15 12:54 PM:
-------------------------------------------------------------
This proposal strikes me as a touch naive, unless it also includes an unspoken
proposal for mechanics not yet invented for reporting from the libsvn_client
layer to the client itself that a change-of-URL event has occurred, or for
including a potentially costly working copy pre-scan for switched subtrees.
'svn switch' isn't used only change the URL of the target of the operation, but
to restore order to the URLs of all items *beneath* the target tree. For
example, if you checkout a working copy of a trunk and then switch some subtree
items within that working copy to their branch-based counterparts, you can use
'svn switch URL-OF-TRUNK /path/to/working/copy' to restore the whole tree back
to a reflection of the trunk. In today's codebase, the client would know that a
switch was requested because of the presence of a target_url. But if it
naively compared that target_url with the URL of the working copy target, it
would find them identical. We wouldn't want to report this operation as a mere
"update" if, in fact, our whole plan here is to distinguish switch operations
in our notifications.
In this case, I believe the simpler approach is also the better one -- if the
user issued a 'switch' command, report a switch; otherwise, report an update.
was (Author: cmpilato):
{noformat:nopanel=true}
This proposal strikes me as a touch naive, unless it also includes an unspoken
proposal for mechanics not yet invented for reporting from the libsvn_client
layer to the client itself that a change-of-URL event has occurred, or for
including a potentially costly working copy pre-scan for switched subtrees.
'svn switch' isn't used only change the URL of the target of the operation, but
to restore order to the URLs of all items *beneath* the target tree. For
example, if you checkout a working copy of a trunk and then switch some subtree
items within that working copy to their branch-based counterparts, you can use
'svn switch URL-OF-TRUNK /path/to/working/copy' to restore the whole tree back
to a reflection of the trunk. In today's codebase, the client would know that a
switch was requested because of the presence of a target_url. But if it naively
compared that target_url with the URL of the working copy target, it would find
them identical. We wouldn't want to report this operation as a mere "update"
if, in fact, our whole plan here is to distinguish switch operations in our
notifications.
In this case, I believe the simpler approach is also the better one -- if the
user issued a 'switch' command, report a switch; otherwise, report an update.
{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)
