[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: 2007-12-01 19:42:45 CET

>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

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.