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: phosphan_at_tigris.org
> To: danielsh_at_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 phosphan_at_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?
Received on 2010-06-29 21:20:22 CEST