On 20.08.2014 01:34, Gavin Lambert wrote:
>> Fixed the focus issue in r25781
>> https://code.google.com/p/tortoisesvn/source/detail?r=25781
>
> Thanks. Any way to stop it beeping?
https://code.google.com/p/tortoisesvn/source/detail?r=25784
>
>>> 4. There doesn't seem to be any easy way to search for properties or property history from the GUI -- in particular I was trying to find what commit last changed a property or even getting something like a Blame for the property to see when a specific subvalue was added.
>>
>> I know, but I don't know how to improve that. I'm open for suggestions.
>
> Maybe the filter search could accept "svn:ignore" or "prop=svn:ignore" or something like that to only include revisions that include changes to that property on items? With some way to distinguish property changes from other changes (or hide non-property changes) from the file list at the bottom too? (Currently both kinds of change just show "Modified" with no other visible difference; it's not until you double-click something that it will then show "Normal (properties only)".)
Problem is that property changes like text diffs are not part of the
data we get from the log. So the log dialog has no idea which properties
have changed in a revision.
even the info whether there were text and/or property changes is not
available with pre-1.8 servers.
>
>>> 6. On a somewhat related note, with "include merged revisions" ticked the "show only affected paths" option becomes fairly useless as it seems to compare the full path down to the repository root (including trunk/branch name), which means that it will never show anything from the merged branches.
>>
>> It's still useful for the non-merged revisions.
>> Or would you recommend to disable that checkbox?
>
> Mostly I was hoping that there'd be some way for it to "follow" the branches. eg. if the current path was /trunk/foo/bar/ and you clicked on a revision that was merged to /trunk from /branches/baz, then it would include changes to /branches/baz/foo/bar/ in the list. (And also be able to do the same for a grandparent merged revision, etc.)
>
> I know this is probably tricky given that SVN's merge tracking is rudimentary at best. But it'd be nice. :) (And there must be some data that it's using to show the merged revisions in the first place.)
That would be nice, yes. But svn lacks an API to get that information
fast - it would take ages to get that information with the available
APIs, and most likely the repo admin would start blocking your IP if I
would implement something like this because it would look like you're
flooding the server with requests :)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3086971
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2014-08-20 20:55:52 CEST