Re: svn commit: r1211199 - Fix issue #4057 "don't record non-inheritable mergeinfo ..."

> Author: pburba

> Date: Tue Dec  6 22:04:22 2011
> New Revision: 1211199
>
> URL: http://svn.apache.org/viewvc?rev=1211199&view=rev
> Log:
> Fix issue #4057 "don't record non-inheritable mergeinfo in shallow
> merge if entire diff is within requested depth".
>
> * subversion/libsvn_client/merge.c
>
>   (calculate_merge_inheritance): Don't unconditionally set non-inheritable
>   mergeinfo on the merge target if the operational depth is shallow.
>   Instead rely on the caller to determine if this is necessary.
[...]

>     WC_PATH_HAS_MISSING_CHILD is true if WC_PATH is missing an immediate child
>     because the child is switched or absent from the WC, or due to a sparse
> -  checkout -- see get_mergeinfo_paths().
> +  checkout (see get_mergeinfo_paths) or because DEPTH is shallow
> +  (i.e. < svn_depth_infinity) and the merge would affect a child if
> +  performed at a deeper depth.

Does the phrase "and the merge would affect a child" apply to the parameter as a whole?  It sounds like it's asking the caller to determine whether the diff would have affected a missing child in some cases but not in other cases.  (I haven't tried to see whether the caller actually does make that determination in the other cases.)  More concretely: if WC_PATH is missing an immediate child because the child is switched or absent from the WC, or due to a sparse checkout, then I think the caller should pass TRUE only if the diff would affect that child.  Maybe that's what you meant already.

- Julian

>     Perform any temporary allocations in SCRATCH_POOL. */
> static svn_error_t *
> @@ -4543,9 +4545,7 @@ calculate_merge_inheritance(svn_boolean_
>     {
>       if (wc_path_is_merge_target)
>         {
> -          if (wc_path_has_missing_child
> -              || depth == svn_depth_files
> -              || depth == svn_depth_empty)
> +          if (wc_path_has_missing_child)
>             {
>               *non_inheritable = TRUE;
>             }
Received on 2011-12-07 12:27:32 CET