In the conflict resolver, add way to limit the path scope within which we try to track down additions. This can be used to avoid traversing history into a different branch, for example. Like the stop-on-copy mechanism, this isn't always going to be correct for any given situation.
In the conflict resolver, add way to limit the path scope within which we
try to track down additions. This can be used to avoid traversing history
into a different branch, for example. Like the stop-on-copy mechanism,
this isn't always going to be correct for any given situation.

Fixes a problem I encountered while playing around with reverse-merged
additions, where a merge was erroring out because we tried merging a path
from a revision where it didn't exist yet.
Perhaps this introduces other problems. The current test coverage is
not broad enough to be sure about this.

* subversion/libsvn_client/conflicts.c
  (find_added_rev_baton): Add parent_repos_relpath.
  (find_added_rev): If parent_repos_relpath is set, only consider location
   segments where the node existed within this parent_repos_relpath.
  (get_incoming_delete_details_for_reverse_addition,
   conflict_tree_get_details_incoming_add,
   conflict_tree_get_details_incoming_add): Set a NULL parent_repos_relpath
    for now. We can revisit these later, keep the current behaviour fow now.
  (merge_incoming_added_dir_replace): Make sure we don't try to merge from
   a revision where the node does not exist yet, e.g. in case it was at some
   point copied from a different directory to its current location.


git-svn-id: f8a4e5e023278da1e04e203c7fe051e3c4285d88@1746156 13f79535-47bb-0310-9956-ffa450edef68

YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion,YueLinHo/Subversion