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

Re: Proposal to implement get_commit_and_merge_ranges from FS

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 25 Jan 2008 09:30:26 -0500

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

This is an archived mail posted to the Subversion Dev mailing list.