Reflective merges are faulty

http://subversion.tigris.org/issues/show_bug.cgi?id=2897







------- Additional comments from kameshjtigris.org Wed Oct 24 06:34:01 -0700 2007 -------
My implementation proposal to fix this issue.
---------------------------------------------
1)Current limitation in backend mergeinfo storage:
We have 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 paths.)
In r53 you merged -r15 from '/trunk' to '/fb'.(Puts two
record on mergeinfo for
this paths.)
In r56 you merged -r18 from '/trunk' to '/fb'.(Puts three
record on mergeinfo
for this paths.)

In this particular case r12 would appear 3 times, which
record to consider to
decide when the merge has occured. 
Record with least revision(commit revision)?, No What if he
reverted r12 from
'/trunk' to '/fb' on r51, Remember we don't record reverse
merges.

My solution to this particular issue,
Change the structure of 'mergeinfo_changed' 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 *rangelist) 

In our context 'mergefrom' -> '/trunk' (target)
               'mergeto'   -> '/feature_branch'(source)

This API will give us 'commit_rev_list' a list of reflective
revisions on
'mergeto' from 'mergefrom' for the rangelist.

------------------------------------------------------------
---------
To unsubscribe, e-mail: issues-unsubscribesubversion.tigris.org
For additional commands, e-mail: issues-helpsubversion.tigris.org