I have the following idea to solve issue 2897.
reflective_rev - commit rev post to merge.
reflected_range - set of merged ranges part of a commit.
non_reflected_change - adhoc local changes that are separate from a
merge forming a port of a same reflective commit.
~ - diff of LHS with RHS.
Sample Dataset for illustration purposes:
- /trunk - trunk (It has only one file test.c)
- /fb - feature branch copy of trunk, copied at r30.
- test.c is 10000 lines.
- /fb is going to modify only within top 1000 lines of test.c
- /trunk is going to modify only within bottom 1000 lines of test.c
- So no chance of conflicts back and forth merges.
SVN operations under consideration:
/fb/test.c has some direct changes in r50, r60
/fb/test.c merged r30:r60 with one local change to test.c at line 5000
committed at r61(*reflective rev*)
/fb/test.c has some direct changes in r70, r80
Merge /fb to /trunk working copy Should merge r50, r60, *line5000 change
*only* in r61*, r70, r80.
To merge *line5000 change in r61* (non_reflected_change)
I propose to implement 'non_reflected_file_changed' a
const char *mine,
const char *older,
const char *yours,
* get reflected_merged_rev_start, reflected_merged_rev_end (The revs
from trunk that got merged to feature branch)
* /fb/test.c@older_rev call this X
* merge (/trunk/test.c@reflected_merged_rev_start ~
/trunk/test.c@reflected_merged_rev_end) on to X
* merge (X ~ /fb/test.c@yours_rev) on to target (This should apply only
the non-reflected portions of change) i.e 'adhoc change in line 5000 as
a part of commit r61'.
* It would work well as long as only one rev range is part of the
commit, it would be more complex if we have adhoc set of revisions
merged as a part of a commit.
* It would be very difficult to take care of the cases where your
subtree of merge target has its own reflection history.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Dec 5 17:23:15 2007