C. Michael Pilato wrote:
> 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* ?
Somewhat closer, it was storing the *full mergeinfo*, Now I need only
'mergeinfo-added'.
>
>> 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?
Yes.
> Why only mergeinfo additions -- aren't the subtractions interesting, too?
>
I am not interested in substractions as we don't support repeat 'merge
reversal'.
With regards
Kamesh Jayachandran
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-25 15:53:13 CET