[PATCH][merge-tracking]Fix repeat merge problem while subtree of merge target having overlapping merge already

Hi All,

Problem: (If this description is boring jump to 'Story' section.)

   "Sub tree 'S' of a parent tree 'P' has already been merged of certain
    revisions say rN-M of some path 'U/corresponding_dir_of_S', Where N < M.
    We try to merge a working copy of 'P' for rA-B of 'U', where 'A-B'
    intersects with 'N-M'
    This intersection could result in conflicting merges."
  i.e
   P = WC of http://localhost/svn/repos/branches/b1 (assume to be latest)
   S = WC of http://localhost/svn/repos/branches/b1/src (assume to be latest)
   U = http://localhost/svn/repos/trunk
   N = 25
   M = 30
   Merged http://localhost/svn/repos/trunk/src -r25:30 to WC of /branches/b1/src(S).
   Merging http://localhost/svn/repos/trunk -r27:35 to /branches/b1(P)
   could give conflict because we already merged few revisions for 'src'.

  This scenario is captured in 'avoid_repeated_merge_on_subtree_with_merge_info' of,
   http://svn.collab.net/repos/svn/branches/merge-tracking/subversion/tests/cmdline/merge_tests.py
--------------------------------------------------------------------------

Story: Ignore if you want.
       Just would like to describe it to record how I solved this problem.

   Four months back I took up the responsiblity to address repeat merge
   problem if subtree of the merge target has some overlapping with that of the
   current merge parent target.

   I tried solving the problem in a complex way (cut the parent tree multiple
   subtrees and run merge on each subtree.), few of my trials in this
   direction was not successful at all.

   In this connection I had a call with Mike. P and Dan to see how better we
   can solve this problem.

   I asked how mixed revision 'svn update' works.
   Mike has responded 'Some set_path... Beyond which I did not understand :)'

   Finally we came up with three abstract approaches,
   1. Cutting the trees to multiple subtrees, running the merge on each tree.
   2. Describe about our working copy subtree mergeinfos to update-report. And
      make the 'update-report' handle this case.
   3. Use ra_replay for each revision extract we want.

  I was trying to summarize the above 3 three approaches and send a mail to
  list to see what the dev@subversion think.

  I first sent my draft to Mike and Dan to see if at all I missed anything.

  Mike was frank enough to disclose that draft was bit boring and needs to be
  more lively.
  He has given valuable clues on how to improve it.

  I reworked on the draft, while explaining solution 2 (svn update on a mixed
revison like ....), I have decided to understand what that magical 'set_path
and Co.' calls are for(Mike was saying something on the call!)?

  I looked at the reporter docs for all the hooks and went to bed.

  All of a sudden before falling asleep The following simple idea striked.....

--------------------------------------------------------------------------

Simple Idea:
  Step 1. Get all nodes having 'svn:mergeinfo' using svn_client__get_prop_from_wc.
  Step 2. In the diff_editor of the parent merge call delete_path on those
          overlapping subtress obtained from the Step 1.

--------------------------------------------------------------------------

Actual implementation:
  In reality delete_path approach did not work. When I called 'delete_path' I
  got 'Skipping ...' notification, still my problematic subtrees
  getting merged and causing conflict.

  One idea sparked, why not call 'set_path' on a reporter by giving the
  'start_revision' same as 'end_revision', This idea has helped me in
  making the 'subtree merge' a 'no op' which is half of my problem.

  Other half is to run a merge on this excluded subtrees.
  Got 'Working copy locked' kind of messages.

  Finally came up with the following solution which solved all my problem.

  * Implemented 'do_subtree_merges' which would call 'do_merge' or
    'do_single_file_merge' on excluded subtrees identified by
    'svn_client__get_prop_from_wc'.
    This function would set the 'subtrees_having_mergeinfo' with all such
    excluded paths so that subsequent do_merge on a parent path would call
    'no op set_path' on these paths.
  * Modified do_merge to accept 'subtrees_having_mergeinfo' to exclude the
    subtrees having overlapping merges using 'no op set_path' on them.
  * Modified 'svn_client_merge3' and 'svn_client_merge_peg3' to first do a
    merge on each 'subtrees_having_mergeinfo'

Ran make check and davautocheck all the tests were passing.

Refer the attached patch for details.
--------------------------------------------------------------------------

Small concern with the patch:
I use the same 'merge_cmd_baton' of 'svn_client_merge3' and
'svn_client_merge_peg3' in each subtree merges.
I had a concern with this approach as I felt
'added_path, target, url, path, dry_run_deletions' of merge_cmd_baton
can not be shared by different 'merges'.

I tried the following to see what happens with this approach.
Reused merge_tests.py testcase 40 to create the basic repeat merge problem.
From some other Working copy added a file 'copy_of_B/F/E/gamma' and
dir 'copy_of_B/F/E/mydir' in revisions 7 and 8 respectively.
In revision 9 deleted copy_of_B/F/E/alpha.

I merged 3:9 of /A/B to copy_of_B(dry-run and actual run),
I got the proper results and proper output.

I duplicated merge_cmd_baton on each merge with custom modification to
'target, url' reflecting the subtree merge.

Got the same results with this duplication.

So decided to use the same merge_cmd_baton on each merges.

With regards
Kamesh Jayachandran

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org