Kamesh Jayachandran <kamesh@collab.net> writes:
> 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.
Clearly, this would be the ideal behavior, yes! :-)
> 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)
In other words, because rP, rQ, and rR fall in between rX and rY, they
are omitted as undesirable purely on numeric grounds, even though they
were on /fb while the other stuff in rX:Y was on trunk?
> What to fix: We should fix this negation logic to negate the 'commit
> rev rZ' rather than what got merged(rX:Y).
I didn't understand that sentence, sorry.
My understanding is that in rZ, the svn:mergeinfo on /fb would be
changed to note all the /trunk revisions in the range rX:Y. Call that
set {R}. When we merge /fb back to /trunk, nothing from {R} should be
included. But rP, rQ, and rR are not in {R}, since they were
committed directly on /fb, and trunk has never seen them.
So my question is, immediately after rZ, does the svn:mergeinfo on /fb
accurately reflect exactly what has been merged in from elsewhere? If
not, is there a good reason why not?
> 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?
Why does r12 appear 3 times? It was only merged once.
(Please remember that I'm just coming at this fresh, so I may not have
certain assumptions / understandings that you have.)
> 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.
I don't understand what the phrase "reverted r12 from '/trunk' to
'/fb' on r51" means. Do you mean remove r12 from /trunk and put it
into /fb, all in one commit? (But it is already in /fb...)
> 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'.
Could you show the precise structure of the proposed new table?
It would also help us newcomers if you would use longer sentences,
with more context, and fewer back-references (for example, I have no
idea what "the revert" refers to in the above paragraph). I'm having
a lot of trouble understanding exactly what's being proposed here. I
think this is partly because there is much more knowledge in your head
than in mine. You may have to explain things that are obvious to you,
because they are not obvious to others who haven't been deep into the
merge-tracking code :-). Thanks.
> 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!
I think I'll understand the rest of this proposal when I understand
the answers to my previous questions.
Thanks,
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 27 02:58:50 2007