Uploaded image for project: 'Subversion'
  1. Subversion
  2. SVN-3666

Assertion frb->last_filename == NULL fails in libsvn_client/blame.c

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: 1.6.15
    • Component/s: libsvn_client
    • Labels:

      Description

      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://thread.gmane.org/gmane.comp.version-control.subversion.user/98666/focus=98721

      Original issue reported by phosphan

        Attachments

        1. 1_issue-3666-recipe.sh
          0.7 kB
          C. Michael Pilato

        Issue Links

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              subversion-importer Subversion Importer

              Dates

              • Created:
                Updated:
                Resolved:

                Issue deployment