subversion-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Zhakov (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (SVN-4006) Make "svn switch" say "Switched" instead of "Updated" or "At"
Date Sun, 18 Oct 2015 12:55:05 GMT

    [ 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)

Mime
View raw message