[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: David Glasser <glasser_at_davidglasser.net>
Date: Sun, 27 Jan 2008 10:39:15 -0800

So this is to implement 2897.

Is it possible to show a simple test case that is handled very well by
the 2897 branch (before the anti-sqlite changes broke your API) and
which is completely unacceptable without 2897 (handled poorly by
reintegrate, etc)? I'm still leaning strongly towards thinking that
2897 is way too much complexity for not much benefit. Again, we never
promised that svn 1.5 would contain massively improved merge
*algorithms*; we just promised that it would do a better job of merge
*tracking*: eliminating the need to remember revision numbers etc.

--dave

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

-- 
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 19:39:28 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.