Re: Proposal to implement get_commit_and_merge_ranges from FS

On Jan 27, 2008 1:36 PM, David Glasser <glasser_at_davidglasser.net> wrote:
> On Jan 25, 2008 5:47 AM, Kamesh Jayachandran <kamesh_at_collab.net> 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',
> > }
> >
> > 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.
> >
> >
> > Possible solutions:
> > We can maintain this per commit data in a separate place other than the one
> > where revprops sit. Provide mechanisms to retrieve from this location.
> >
> >
> > Want to know what others think about this.
>
> I guess what concerns me about this is that it's repository-global, so
> unlike most svn operations, in a repository like the ASF (say) the
> queries for one project are going to have to look through all the data
> in the rev range for all the other projects.

My understanding was that the existing merge algorithm determines what
revisions need to be merged. Once the revisions have been determined,
it then needs to check if any of those revisions are "reflective".
That does not sound like a repository wide scan to me.

You have a valid point/question in your other mail though. As in what
are the use cases this would solve that the reintegrate option would
not.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org