Re: Status on issue-2897 branch

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?

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.

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.)

--dave

-- 
David Glasser | glasser_at_davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org