Paul Burba wrote on Fri, Sep 23, 2011 at 10:24:07 -0400: > On Fri, Sep 23, 2011 at 1:06 AM, Daniel Shahaf <[email protected]> wrote: > > [[[ > > Index: subversion/libsvn_client/merge.c > > =================================================================== > > --- subversion/libsvn_client/merge.c (revision 1174351) > > +++ subversion/libsvn_client/merge.c (working copy) > > @@ -6822,7 +6822,7 @@ do_file_merge(svn_mergeinfo_catalog_t result_catal > > &inherited, svn_mergeinfo_inherited, > > merge_b->ra_session1, target_abspath, > > MAX(revision1, revision2), > > - 0, /* Get all implicit mergeinfo */ > > + MIN(revision1, revision2), > > ctx, scratch_pool, iterpool); > > > > if (err) > > ]]] > > > > This reverts a hunk of r1035894 (the revision merging the > > issue-3668-3669 branch to trunk). > > Hi Daniel, > > Yes, that should have been reverted, must have messed up some conflict > resolution. Thanks for spotting that. Committed the above patch in > r1174797 , nominating for backport in a moment. > > FWIW it's fairly harmless since after r1035894 was reverted, > get_full_mergeinfo() no longer filtered implicit mergeinfo and any > implicit mergeinfo obtained which is older than the requested merge of > REV1:REV2 isn't used anywhere else in do_file_merge. > > Paul
In other words, the old revisions' mergeinfo would have been fetched from the server and then ignored/discarded? Thanks for the fix/information, Daniel
