Looks like we have an assertion failure in 'blame -g'. Patrick debugged it and has a prognosis, but I don't know enough about this code to be able to comment on it. Forwarding to this list for more eyes.
> ---------- Forwarded message ---------- > Date: Tue, 29 Jun 2010 13:38:51 > From: phosp...@tigris.org > To: danie...@tigris.org > Subject: [Issue 3666] New - Assertion frb->last_filename == NULL fails in > libsvn_client/blame.c > > http://subversion.tigris.org/issues/show_bug.cgi?id=3666 > Issue #|3666 > Summary|Assertion frb->last_filename == NULL fails in > libsvn_client/blame.c > Component|subversion > Version|trunk > > > > > > > ------- Additional comments from phosp...@tigris.org Tue Jun 29 03:38:50 > -0700 2010 ------- > As discussed on the subversion users mailing list I found a problem when > trying > to annotate a file including merge info. > Use the following commands to reproduce the issue: > ------------ > svnadmin create repo > mkdir work > touch work/a.txt > svn import work file:///repo/trunk -m "imported" > rm -rf work > svn checkout file:///repo/trunk work > cd work > svn copy . file:///repo/branch -m "branched" > svn switch file:///repo/branch > echo foo > a.txt > svn commit -m "changed on branch" > svn switch file:///repo/trunk > svn merge file:///repo/branch > svn commit -m "merged" > svn update > echo bar >> a.txt > svn commit -m "changed on trunk" > svn update > svn annotate -g -r 4:5 a.txt > ------------ > > Expected result: Some annotations. > Got result: > In file > 'D:\Development\SVN\Releases\TortoiseSVN-1.6.8\ext\subversion\subversion\libsvn_client\blame.c' > line 487: assertion failed (frb->last_filename == NULL) > > (or similar, Daniel Shahaf reproduced it using current trunk). > > In the debugger it looked like subversion only wants to get info for exactly > one > revision before the first revision you ask for in the "blame" command. When > you > include merged revisions you get much more information than you asked for. > For the repository that I used originally when I found this bug I stepped > through the loop skipping the assertion and stopped counting after almost a > dozen revisions where only one was expected. > > I am not sure what is the right way to deal with this problem: Exclude the > merge > info for the revision before the range starts or fix the check to allow more > revisions here?
