David Glasser wrote:
> On Dec 12, 2007 11:40 AM, David Glasser <glasser@davidglasser.net> wrote:
>
>> On Dec 12, 2007 8:51 AM, David Glasser <glasser@davidglasser.net> 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?
>>>
>>> (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?)
>>>
>> Wouldn't the return value be more natural as a hash? I guess you'd
>> have to sprintf the keys (commit revs) to strings. And maybe you do
>> rely on the sort order; I dunno.
>>
>
> Note that you don't have to sprintf; you just have to make sure that
> the revnums are in pool-allocated memory, and pass
> sizeof(svn_revnum_t) as the size arg in apr_hash_get/set. See the use
> of pb->rev_map in libsvn_repos/load.c, eg.
>
>
Hashtable may not workout as again I need to sort when I consume with
other range API.
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:25:41 2007