On Jan 27, 2008 11:46 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>
> 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.
No, the existing algorithm might say something like "r1000-4000 need
to be merged". Maybe only five of these revisions actually change the
project/branch in question, but the way the diff algorithm works, this
doesn't matter, since it isn't iterating over the revisions. Kamesh's
design for his new API would then make us iterate over all thse
"mergeinfo" files/revprops for all the revs from 1000-4000.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
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-27 21:56:47 CET