Julian Foad wrote on Tue, Feb 17, 2015 at 16:26:54 +0000:
> This issue looks like one that we should fix for 1.9.
>
> [[[
> Several of the blame functions don't work properly when start=HEAD and end=N
> because they compare start and end to work out whether start is less than or
> greater than end. At least these functions need attention:
>
> svn_client_blame5 gets younger_rev wrong
> svn_ra_get_file_revs2 gets the capability check wrong
> svn_ra_serf__get_file_revs gets the peg_rev wrong
>
> See also r1568872 which fixed a similar problem with log.
> ]]]
>
Stupid question: can't we just redefine svn_revnum_t as unsigned long,
so that SVN_INVALID_REVNUM becomes ULONG_MAX, and all these comparisons
— in all codepaths, not just reverse blame — start DTRTing?
It doesn't break big repositories, since it doesn't decrease the domain
of valid non-negative revision numbers. But it breaks some uses of
SVN_INVALID_REVNUM (passing it to a domain that represents -1 and
ULONG_MAX distinctly, and then reading it back), so I assume we can't do
it until 2.0 ☹
> Philip wrote on IRC just now,
>
> [[[
>
> $ svn blame -rHEAD:1000000 ../src/README
> svn: E235000: In file '../src/subversion/libsvn_client/blame.c' line 497: assertion failed ((frb->last_filename == NULL) || frb->include_merged_revisions)
>
> [...] I think it is a consequence of things like blame.c:659 which does younger_end.value.number = MAX(start_revnum, end_revnum);
> ]]]
>
> Anyone want to take a look at it?
I am behind the libsvn_client part of this. Am I expected to take
ownership of these bugs?
Asking because my circumstances have changed in the 18 months since
I wrote this code: my svn time budget is different today than it was
then. (I'll try to at least review the backports if I can, but if I'm
expected to do more, just say so.)
Cheers,
Daniel
Received on 2015-02-18 01:10:32 CET