Login | Register
My pages Projects Community openCollabNet

Discussions > dev > Re: "Display 'moved here' and 'moved away' status in working copy status list

Project highlights: :. Download .: :. Support .: :. FAQ .: :. Translations .: :. Donate .: :. Report Bug .:

tortoisesvn
Discussion topic

Back to topic list

Re: "Display 'moved here' and 'moved away' status in working copy status list

Author Stefan Hett <stefan at egosoft dot com>
Full name Stefan Hett <stefan at egosoft dot com>
Date 2016-09-28 08:44:22 PDT
Message On 9/28/2016 4:52 PM, Ivan Zhakov wrote:
> On 28 September 2016 at 12:49, Stefan Hett <stefan at egosoft dot com> wrote:
>> On 9/28/2016 11:34 AM, Ivan Zhakov wrote:
>>> Hi,
>>>
>>> Subversion records moves as first-class operation in the working copy
>>> since version 1.8 [1]. For example here is how 'svn status' looks for
>>> working copy where file 'foo.txt' was renamed to 'bar.txt':
>>> [[[
>>> A + bar.txt
>>> > moved from foo.txt
>>> D foo.txt
>>> > moved to bar.txt
>>> ]]]
>>>
>>> But TortoiseSVN only displays this information in a tooltip in the
>>> status list. I suggest adding 'moved here' and 'moved away' to
>>> TortoiseSVN. See the attached patch and screenshot.
>>>
>>> [1] https://subversion.a​pache.org/docs/relea​se-notes/1.8.html#mo​ves
>>>
>>>
>> Feedback from a user's point of view (if that's helpful):
>> How about only displaying a single entry for both operations as in:
>>
>> Path Extension Status
>>
>> bar.txt txt moved from foo.txt
>>
>>
>> IMO that would make more sense to the user and simplifies the
>> use-case/UI a bit.
>> It will also solve the problem with the current approach that if you
>> have two renames/moves, you don't really see which entries are related
>> to one another.
>>
>> I certainly can't say whether combining the two entries to a single one
>> will break current use-cases and/or require much work to adjust these,
>> so it might be out of question and you already considered (and therefore
>> rejected) that idea.
Thanks for taking the time to review my points, Ivan.

> 1. This will require to user to configure Status column to be very
> wide. Just imagine something like:
>
> Path
> subversion\bindings​\javahl\src\org\​apache\subversion\​javahl\ClientExcept​ion.java
> moved from subversion\bindings​\javahl\src\org\​tigris\subversion\​javahl\Exception.ja​va
Possible solution: Use a relative path to display there (moved from
...\tigris\subvers​ion\javahl\Excepti​on.java) and add a mouse-over
tooltip to display the full path.
Also I the common case of a simple rename (rather than a move(+rename))
would still benefit from that style without that problem (since there
only the old filename would be displayed).
Certainly for the general case it can end up with a rather long path
(but then I take it it's ok that for these cases the column width would
have to be manually extended to see the full name (or use mouse over
tooltips to show the full path while in the column the path would be
displayed truncated as in "moved from subversion\bind...").

> 2. This will be be inconsistent with Subversion command line output
Personally I wouldn't buy that as an argument against a change. Clients
don't have to be necessarily all consistent between one another. The
command line client is designed around a fundamentally different
environment (the command line) than the TSVN client (GUI). That opens up
ways to improve the representation of things in TSVN which are not
possible with the command line client. Furthermore the CMD-client has a
completely different requirement set than TSVN needs to take into
account and also a different target audience and a different use-case set.
Therefore IMO it's absolutely fine, if TSVN displays things differently
than the command line client does, if it serves a purpose, makes sense
and/or is a reasonable extension/improvement over the command line client.

> 3. There will be no options for user to perform operations on deleted
> side of move
That sounds merely like an argument to extend the context menu for these
entries. For instance the context menu could display a "convert to
copy"-operation (which would equal the undoing of the deletion of the
old file). Obviously, that certainly requires some more work (and there
might be more cases like these --- as stated: I didn't investigate in
detail, so I completely take your judgment if you say it's too much work
or would complicated the UI/code too much).

--
Regards,
Stefan Hett

« Previous message in topic | 4 of 5 | Next message in topic »

Messages

Show all messages in topic

"Display 'moved here' and 'moved away' status in working copy status list Ivan Zhakov <ivan at visualsvn dot com> Ivan Zhakov <ivan at visualsvn dot com> 2016-09-28 02:34:34 PDT
     Re: "Display 'moved here' and 'moved away' status in working copy status list Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2016-09-28 02:49:24 PDT
         Re: "Display 'moved here' and 'moved away' status in working copy status list Ivan Zhakov <ivan at visualsvn dot com> Ivan Zhakov <ivan at visualsvn dot com> 2016-09-28 07:52:48 PDT
             Re: "Display 'moved here' and 'moved away' status in working copy status list Stefan Hett <stefan at egosoft dot com> Stefan Hett <stefan at egosoft dot com> 2016-09-28 08:44:22 PDT
                 Re: "Display 'moved here' and 'moved away' status in working copy status list steveking Stefan Küng 2016-09-28 10:24:55 PDT
Messages per page: