[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 2897] Reflective merges are faulty

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-10-24 16:02:34 CEST

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 <kameshj@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
Received on Wed Oct 24 16:02:37 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.