[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: Mark Phippard <markphip_at_gmail.com>
Date: Sun, 27 Jan 2008 08:56:26 -0500

On Jan 25, 2008 8:47 AM, Kamesh Jayachandran <kamesh_at_collab.net> wrote:

> 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.

I do not see anything wrong with this as a solution. I assume in BDB
we would just have a new table for this info (maybe you already do).
In fsfs we could add a new folder to the repository db named
"mergeinfo". Whenever a commit is done that alters mergeinfo, you
could create a file with the same name as the revision that stores
this information. If the commit does not alter mergeinfo, do not
create a file. You could even follow the same sharding scheme as the
revs folder, just for consistency.

I do not see any problem with this approach.

-- 
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
Received on 2008-01-27 14:56:39 CET

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