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

Re: Status on issue-2897 branch

From: David Glasser <glasser_at_davidglasser.net>
Date: 2007-12-12 20:40:08 CET

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.

Also, is commit_rangelist a list of revnums or of ranges? Is
merge_ranges_lists a list of lists of revnums, or a list of
rangelists?

--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
Received on Wed Dec 12 20:40:20 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.