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

added subtrees with non-inheritable mergeinfo cause spurious subtree mergeinfo

    XMLWordPrintableJSON

    Details

      Description

      As Julian noted in
      http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/merge.c?r1=1205867&r2=1205866&pathrev=1205867
      there is a bug in the merge code when tracking the roots of subtrees added by a
      merge in libsvn_client/merge.c:
      
      [[[
      --- subversion/trunk/subversion/libsvn_client/merge.c	2011/11/24 15:09:12	1205866
      +++ subversion/trunk/subversion/libsvn_client/merge.c	2011/11/24 15:09:16	1205867
      @@ -2795,6 +2795,7 @@
               notify_abspath = moved_to_abspath;
           }
       
      +  /* Update the lists of merged, skipped, tree-conflicted and added paths. */
         if (notify_b->merge_b->sources_ancestral
             || notify_b->merge_b->reintegrate_merge)
           {
      @@ -2856,6 +2857,9 @@
                 else
                   {
                     added_path_parent = svn_dirent_dirname(added_path, pool);
      +              /* ### Bug. Testing whether its immediate parent is in the
      +               * hash isn't enough: this is letting every other level of
      +               * the added subtree hierarchy into the hash. */
                     if (!apr_hash_get(notify_b->added_abspaths, added_path_parent,
                                       APR_HASH_KEY_STRING))
                       is_root_of_added_subtree = TRUE;
      ]]]
      
      This went unnoticed for so long because the only consumer of ADDED_ABSPATHS,
      merge.c:record_mergeinfo_for_added_subtrees() only did anything with non-roots
      if they had non-inheritable mergeinfo.  In that case spurious mergeinfo could be
      created, but it takes a fairly tortured use case to do so.
      

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                pburba Paul Burba
              • Votes:
                0 Vote for this issue
                Watchers:
                0 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: