[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 3666] New - Assertion frb->last_filename == NULL fails in
From:       phosphan () tigris ! org
Date:       2010-06-29 10:38:51
Message-ID: iz3666 () subversion ! tigris ! org
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=3666
                 Issue #|3666
                 Summary|Assertion frb->last_filename == NULL fails in libsvn_c
                        |lient/blame.c
               Component|subversion
                 Version|trunk
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|libsvn_client
             Assigned to|danielsh
             Reported by|phosphan






------- Additional comments from phosphan@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?

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2627303

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]