You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <eh...@gmail.com> on 2007/10/24 13:45:46 UTC
Re: [Issue 2897] Reflective merges are faulty
Kamesh,
Could you please discuss proposals like this (and process) on the
mailing list? I'm seeing a tendency to discuss more and more in the
issue tracker, while we have agreed that we'd discuss on dev@, adding
references to IZ.
Thanks!
bye,
Erik.
On 24 Oct 2007 13:34:01 -0000, kameshj@tigris.org <ka...@tigris.org> wrote:
> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>
>
>
>
>
>
> ------- Additional comments from kameshj@tigris.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-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: issues-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 2897] Reflective merges are faulty
Posted by Kamesh Jayachandran <ka...@collab.net>.
Hi Erik,
I thought of proposing this in the dev@ list after hearing from Dan on
http://subversion.tigris.org/issues/show_bug.cgi?id=2897#desc19.
I recorded what I have studied in desc20, though I mentioned it as
proposal, It is more of a record of thought.
With regards
Kamesh Jayachandran
Erik Huelsmann wrote:
> Kamesh,
>
> Could you please discuss proposals like this (and process) on the
> mailing list? I'm seeing a tendency to discuss more and more in the
> issue tracker, while we have agreed that we'd discuss on dev@, adding
> references to IZ.
>
>
> Thanks!
>
> bye,
>
>
> Erik.
>
>
>
> On 24 Oct 2007 13:34:01 -0000, kameshj@tigris.org <ka...@tigris.org> wrote:
>
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>>
>>
>>
>>
>>
>>
>> ------- Additional comments from kameshj@tigris.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-unsubscribe@subversion.tigris.org
>> For additional commands, e-mail: issues-help@subversion.tigris.org
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org