Kamesh Jayachandran wrote:
> Hi All,
>
> Problem: Implement get_commit_and_merge_ranges report from a mergeinfo
> in FS.
>
> Interface:
> svn_fs_fs_get_commit_and_merge_ranges
> (apr_array_header_t **merge_ranges_list,
> apr_array_header_t **commit_rangelist,
> svn_fs_root_t *root,
> 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)
>
> Algorithm:
> 1)Record svn:mergeinfo_added_on_targets in this commit as a transaction
> property. Format of this property's value is serialized hash of
> {/target1 -> '/src1: rR,rX-Y\n
> /src2: rS, rA-B\n',
> /target2 -> '/src1: rR,rX-Y\n
> /src2: rS, rA-B\n',
> }
Oh, you mean exactly like what I *just removed from the BDB code* ?
> 2)Run something like 'svn_repos_history2' between revisions min_commit_rev
> and max_commit_rev to get commits revs where merge_source has been merged
> to merge_target along with their merge ranges.
>
>
> Possible problems:
> Storing it as revprop makes this data to be mutable, which may be
> problematic
> if someone maliciously write some data that causes hash parser to break.
Yeah, that's no good.
So, just to clarify, what you're looking for is mapping of revision numbers
(across a range) to mergeinfo changes made in that revision? Why only
mergeinfo additions -- aren't the subtractions interesting, too?
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-25 15:50:58 CET