Hi All,
Summary: Filter 'Target Reflective Merges on Merge Source', while
merging to Target from merge source.
Consider the following situation
* Create feature branch '/fb' from '/trunk' (results in rX)
* Do some commits on '/fb' (rP, rQ, rR)
* merge '/trunk' to '/fb'(merge few revs rX:Y(current HEAD), commit
results in rZ).
* Do some more commits on '/fb' (rS, rT)
* merge '/fb' back to '/trunk'.
Expected behaviour of last merge:
merge *only* 'rP, rQ, rR, rS, rT' from '/fb' to 'trunk', ie it should
exclude rZ as it is reflective merges from '/trunk' itself.
Actual behaviour of last merge:
Currently this behaviour is broken (issue 2897 just deals with it.), it
merges only rS and rT alone (that is it negates 'rX:Y' from rX:HEAD and
gives rS and rT, remember rX<rP, rQ, rR <rY)
What to fix: We should fix this negation logic to negate the 'commit rev
rZ' rather than what got merged(rX:Y).
We discussed few possible fixes in issue 2897 and finally we came up
with the following finding/proposal.
Current limitation in backend mergeinfo storage:
----------------------------------------------------------------------
We have sqlite table 'mergeinfo' which has the tokenized merge revisions
for each path
for each 'merge+commit'. This information is ambiguous, consider the
following case.
In r50 you merged -r12 from '/trunk' to '/fb'.(Puts one record on
mergeinfo for
this path.)
In r53 you merged -r15 from '/trunk' to '/fb'.(Puts two records on
mergeinfo for
this path.)
In r56 you merged -r18 from '/trunk' to '/fb'.(Puts three records on
mergeinfo
for this path.)
In this particular case r12 merge would appear 3 times, which record to
consider to
decide when the merge has occured?
Take the least revision(commit revision)?, No What if we reverted r12 from
'/trunk' to '/fb' on r51, Remember we don't record reverse merges and
merge back the same on r52.
Proposal to fix this issue
--------------------------------
Change the table structure of 'mergeinfo_changed'(today it is 2 coulum
table of commit_rev, merge_target) almost same as that of mergeinfo and
record the merge range that is getting added(as we are not recording the
revert independently !) in this commit. After all 'mergeinfo_changed'
means 'only changes'.
2)We need a ra API 'svn_ra_get_merge_commit_revs(apr_array_header_t
**commit_rev_list, const char* mergefrom, const char* mergeto,
apr_array_header_t *merge_rangelist)
In our context 'mergefrom' -> '/trunk' (target)
'mergeto' -> '/fb'(source)
This API will give us 'commit_rev_list' a list of reflective revisions on
'mergeto' from 'mergefrom' for the merge_rangelist.
3)We can use this 'svn_ra_get_merge_commit_revs' in libsvn_client to
negate the commit revs.
Any thoughts are welcome!
With regards
Kamesh Jayachandran
P.S: issue 2837 seem to encompass this functionality too, though it can
be reduced to 'identify local edits in a merge from actual merge
itself', which is a much complex problem that our current design can not
solve.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 26 09:17:04 2007