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

Builtin diff produces spurious hunk

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major
    • Resolution: Fixed
    • all
    • unscheduled
    • libsvn_diff
    • None

    Description

      I have a Subversion working copy with libsvn_fs/tree.c version 7519.  I change
      the dag_node_cache_get function to add a pool parameter as follows (note I am
      using GNU diff as an external diff)
      
      $ svn diff --diff-cmd /usr/bin/diff 
      Index: tree.c
      ===================================================================
      --- tree.c      (revision 7519)
      +++ tree.c      (working copy)
      @@ -209,7 +209,8 @@
          isn't cached. */
       static dag_node_t *
       dag_node_cache_get (svn_fs_root_t *root,
      -                    const char *path)
      +                    const char *path,
      +                    apr_pool_t *pool)
       {
         struct dag_node_cache_t *cache_item;
       
      
      That output is exactly what I expect.  However if I use the builtin diff I get this
      
      $ svn diff 
      Index: tree.c
      ===================================================================
      --- tree.c      (revision 7519)
      +++ tree.c      (working copy)
      @@ -209,7 +209,8 @@
          isn't cached. */
       static dag_node_t *
       dag_node_cache_get (svn_fs_root_t *root,
      -                    const char *path)
      +                    const char *path,
      +                    apr_pool_t *pool)
       {
         struct dag_node_cache_t *cache_item;
       
      @@ -4060,7 +4061,7 @@
       
         /* The Subversion filesystem is written in such a way that a given
            line of history may have at most one interesting history point
      -     per filesystem revision.  Either that node was edited (and
      +     per filesystem revision.  Either that node was edited (and
            possibly copied), or it was copied but not edited.  And a copy
            source cannot be from the same revision as its destination.  So,
            if our history revision matches its node's commit revision, we
      
      There's an extra hunk.  The change is a no-op there isn't even any whitespace
      difference.
      

      Attachments

        Activity

          People

            Unassigned Unassigned
            philipm Philip Martin
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: