RE: svn commit: r28158 - in branches/issue-2897/subversion: include/private libsvn_fs_util libsvn_ra_neon libsvn_ra_serf libsvn_ra_svn mod_dav_svn mod_dav_svn/reports

 
>Kamesh Jayachandran <kamesh@collab.net> writes:
>>> + ### Why are we returning an array of 'svn_merge_range_t' objects
>>> + ### below, instead of just 'svn_revnum_t's? Isn't representing
>>> + ### single revisions exactly what 'svn_revnum_t' is for? -Karl
>>
>> Currently we do so to ease the mergeinfo negation, we may go back to
>> revlist once I have solid direction on non-reflective merge editor,
>> which does not negate the reflective rev from the original merge.

>I didn't quite understand that. What's a "non-reflective merge editor"?

Sorry I misunderstood your point. What I mean is 'having revs as Range-list helps in filtering the commit revs from the requested merge range easier', i.e with one call
SVN_ERR(svn_rangelist_remove(requested_rangelist, reflected_rangelist_for_tgt, *requested_rangelist, FALSE, pool));

When we have 'non reflective editor' i.e something like 'svn_client__get_diff_editor' we need not do range list removal, rather apply the individual revs non-reflective merges.

With regards
Kamesh Jayachandran
Received on Sat Dec 1 19:42:56 2007