Hi,
Michael Pilato while discussing over phone about this patch raised a concern what if the subtree does not exist in the repo for the rev with which we call set_path.(no-op set-path)
I just experimented in my $BUILDDIR/subversion/tests/cmdline/svn-test-work/working-copies/merge_tests-40.(at r6)
a)Deleted the file:///path/to/repositories/merge_tests-40/A/copy-of-B/F/E resulted in r7.
b)merged r3:7 of file:///path/to/repositories/merge_tests-40/A/B to A/copy-of-B worked well with this patch without complaining anything while set_path on copy_of_B/F/E for r7.
And hence no issues.
Thanks
With regards
Kamesh Jayachandran
-----Original Message-----
From: Kamesh Jayachandran [mailto:kamesh@collab.net]
Sent: Sun 12/24/2006 1:24 AM
To: dev@subversion.tigris.org
Subject: [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
Received on Sat Jan 6 19:49:03 2007