[merge tracking] Recording merge info when part of the merge is skipped

On Thu, 21 Sep 2006, Kamesh Jayachandran wrote:
...
> >improved handling for skip notifications encountered while performing
> >a merge.
> >
> >* subversion/libsvn_client/diff.c
> > (notification_receiver_baton_t): Change the data type of the
> > nbr_notifications field from apr_int32_t to apr_uint32_t, and
> > skipped_paths from apr_array_header_t to apr_hash_t.
...
> Currently I could not see the value in changing type of 'skipped_paths'
> from 'apr_array_header_t*' to 'apr_hash_t*', As we refer it almost
> always sequentially.

This change is related to the discussion with the Subject line of
"[merge tracking] Recording merge info when part of the merge is
skipped" (which you recently responded to). That discussion hadn't
yet finished at the time I made this commit.

In r21563, we *always* use skipped_paths sequentially. However, this
change laid the groundwork for handling "unexpected skips", as stubbed
out in libsvn_client/diff.c:determine_merges_performed():

      for (hi = apr_hash_first(NULL, notify_b->skipped_paths); hi;
           hi = apr_hash_next(hi))
        {
          ...

          if (nbr_skips < notify_b->nbr_notifications)
            /* ### Use RANGELIST as the merge info for all children of
               ### this path which were not also explicitly
               ### skipped? */
            ;
        }

Here, we want O(1) path lookups while inspecting any children of each
skipped_path, to assure that the child wasn't also skipped before
infusing the child with merge info.

> Now I think we should keep track of 'merged_paths' and 'nbr_skipped'
> rather than 'skipped_paths'.
  if (nbr_skipped > 0)
> loop through merged_paths to set the mergeinfo optimally.
> else
> set the mergeinfo on root of target wc

This approach ignores the fact that merge info is inherited by child
paths. Thanks for the suggestion, though -- it would be much simpler
if we could do it this way (though it would typically consume a lot
more memory, client-side).

p.s. The above discussion in based on the assumption that a skip
notification for a directory doesn't mean that all children of that
directory were skipped as well. This assumption may be incorrect.
Can someone confirm?