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 have finally gotten a chance to review the current state of the
> issue-2897 branch.
>
> It doesn't look like you actually use the returned merge_ranges_list
> anywhere; you just use the commit_rangelist.
>
> ie, all you're asking the repos for is "what revisions between R1 and
> R2 had mergeinfo changes for TO from SOURCE"?
>
> Are you going to need the merge_ranges_list later?
>
Yes. I need this 'merge_ranges_list' to find the non-reflective changes.
> Note that I think I have a way to implement that request in the FS (no
> sqlite), by basically making every noderev with mergeinfo link to the
> previous mergerev where mergeinfo changed in a new tag.
>
>
That would be great!.
> Also, the query you do (in get_commit_and_merge_ranges) seems a little
> bogus as far as inheritance goes. Basically it seems like you find
> the nearest ancestor that has some mergeinfo change somewhere inside
> the revision, and then use exactly that ancestor to do all the later
> queries. However, if the ancestor that MERGE_TARGET inherits its
> mergeinfo from changes over the course of the revision range that
> you're searching (ie, maybe sometimes it's MERGE_TARGET, sometimes
> it's one ancestor, sometimes it's another) that query will be wrong.
> I don't see a trivial way to fix this. (And I would not support
> releasing 1.5 with APIs that suffer from this sort of issue.)
>
>
Thanks for catching that, will fix that. It broke since the recent
change in 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 09:32:48 2007