Am 13.12.2012 21:31, schrieb Stefan Küng:
> Actually, we can not fix this.
> While Subversion has so called peg revisions which should make the
> svn lib automatically find the 'previous' revision in such
> situations, that fails if the copy operation is done from an earlier
> revision than HEAD-1.
Interesting interpretation. As far as I understood peg revisions, they
are for finding the correct path of a file in a different revision, if
it existed there. But I may have underestimated the power of them.
I have (some time ago) worked against the SVN API as well (against a
Java wrapper library called JavaHL) and when I had to follow a bunch of
files file through the revision "forest", I requested log entries and
parsed their copyFromPath and copyFromRevision manually - so my guess
was you had to do the same for Blame previous revision and therefore I
thought the log fix should also fix blame.
Could have saved me some work with using peg revisions more, too. :)
> So unless that is ever fixed in the svn lib, we can do nothing about
> that.
Let's be more fair - at least nothing that does not involve kludgy hacks
for the case when invoking it from the blame viewer.
When invoking it from the log viewer by requesting "compare with
previous", scanning the displayed list of revisions for the largest
number smaller than the selected revision (after unapplying filters and
taking into account the list may be sorted differently) sounds feasible
to me. If no earlier revision is present (because of requested revision
range) falling back to REV-1 should be acceptable. :)
But I understand that you do not regard this as a bug, so consider it as
a feature request instead (and feel free to ignore it, as the workaround
to use the - now fixed - log view is acceptable to me).
The kludgy hack that comes to my mind for the blame request: Do a blame
(or cat or whatever) request against REV-1 (as currently done), and if
the revision cannot be found, do a log request for the file (with peg
revision @REV) with range REV:1 and limit 2 - if only one revision (REV)
is returned it was the oldest (file created there) and you cannot blame
previous; if two revisions (REV and x) are returned, blame against x.
Only requesting log of REV and parsing the file entries would be another
options but since I guess you don't have such parsing code yet, having
the server do it might be a lot simpler.
Anyway, thanks for your insights,
Michael
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3035538
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-12-13 23:26:17 CET