Re: Status on issue-2897 branch

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.

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