valgrind UMRs in "svn merge --record-only"

I'm seeing an unitialised memory read during "svn merge --record-only"
in places like blame_tests.py 10. This happens when
libsvn_client/repos_diff.c:add_directory calls
libsvn_client/merge.c:merge_dir_added which does:

  /* Easy out: We are only applying mergeinfo changes to existing paths. */
  if (merge_b->record_only)
    {
      svn_pool_destroy(subpool);
      return SVN_NO_ERROR;
    }

without setting *state so when add_directory then goes on the check
state it triggers the UMR. One fix would be soemthing like:

Index: subversion/libsvn_client/merge.c
===================================================================
--- subversion/libsvn_client/merge.c (revision 885260)
+++ subversion/libsvn_client/merge.c (working copy)
@@ -2003,6 +2003,8 @@
   /* Easy out: We are only applying mergeinfo changes to existing paths. */
   if (merge_b->record_only)
     {
+ if (*state)
+ *state = svn_wc_notify_state_unknown;
       svn_pool_destroy(subpool);
       return SVN_NO_ERROR;
     }

but I'm not sure that svn_wc_notify_state_unknown is correct. Does
the comment about only applying to existing paths mean that because
this is an add the directory does not exist in the working copy? Does
that mean that svn_wc_notify_state_missing would be better than
svn_wc_notify_state_unknown?

The same code occurs in other places such as merge_dir_deleted,
merge_file_added and while these don't trigger UMRs I suspect that is
down to limited test coverage. Take merge_dir_deleted for example: it
doesn't set either *state or *tree_conflicted. It's even less clear
what the comment about only applying to existing paths means here.

-- 
Philip
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2425507
Please start new threads on the <dev_at_subversion.apache.org> mailing list.
To subscribe to the new list, send an empty e-mail to <dev-subscribe_at_subversion.apache.org>.