David Glasser wrote:
> On Dec 12, 2007 7:48 AM, Kamesh Jayachandran <kamesh@collab.net> wrote:
>
>> Hi All,
>> I changed the 'get-commit-revs-for-merge-ranges' initial implemenation
>> to 'get-commit-and-merge-ranges' as the initial implementation is prone
>> to edge case.
>>
>> I reworked on my original work on 'extract and apply non-reflective
>> changes' later realised one more issue with
>> 'get-commit-and-merge-ranges' API.
>>
>> Today it stands out like this,
>> svn_error_t *
>> svn_ra_get_commit_and_merge_ranges(svn_ra_session_t *session,
>> apr_array_header_t **merge_ranges_list,
>> apr_array_header_t **commit_rangelist,
>> const char* merge_target,
>> const char* merge_source,
>> svn_revnum_t min_commit_rev,
>> svn_revnum_t max_commit_rev,
>> svn_mergeinfo_inheritance_t inherit,
>> apr_pool_t *pool);
>>
>> For the dataset of
>> Merged r30, r32, r36 from /source to /target at r50
>> Merged r40, r42, r46 from /source to /target at r51
>> Current api would give
>> commit_rangelist = [50, 50, 50, 51, 51, 51]
>> merge_ranges_list = [30, 32, 36, 40, 42, 46]
>>
>> Whereas it should give
>> commit_rangelist = [50, 51]
>> merge_ranges_list = [[30, 32, 36], [40, 42, 46]]
>>
>> I am fixing this right now.
>>
>
> Hi Kamesh. Can you clarify in text somewhere exactly what the
> information that this API needs to harvest is? I have some ideas
> about how to better utilize (index and query) Sqlite that I haven't
> put into practice yet; I'd be happy to help with this.
>
> So what are the questions that this API needs to ask? And what is
> your proposed schema?
>
>
The schema change to mergeinfo_changed as already discussed, it will be
same as 'mergeinfo' with just
recording fresh merges on a commit alone recorded on a mergeinfo_changed
table.
The purpose of the API is to give a 1-1 corresponding lists
commit_rangelist of type apr_array_header_t *(comprising
svn_merge_range_t* elements)
merge_ranges_list of type apr_array_header_t *(comprising
apr_array_header_t* elements, each such element's list contains
svn_merge_range_t *)
> (One big question I'm concerned about, looking at that API, is peg-rev
> resolution. What if "merge_target" refers to different, unrelated
> lines of history at min_commit_rev and max_commit_rev?)
>
>
Caller subversion/libsvn_client/merge.c filter_reflected_revisions does
a peg rev lookup and calls the API with relevant paths and revisions.
Thanks for the review
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 13 08:22:32 2007