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
