Re: [Issue 2897] Reflective merges are faulty

Paul Burba wrote:

> On Thu, Apr 11, 2013 at 5:15 PM,  <julianfoad_at_tigris.org> wrote:
>> http://subversion.tigris.org/issues/show_bug.cgi?id=2897
>>
>> User julianfoad changed the following:
>>
>>                 What    |Old value                |New value
>> =============================================================
>>                   Status|NEW                      |RESOLVED
>>               Resolution|                          |FIXED
>>
>> ------- Additional comments from julianfoad_at_tigris.org Thu Apr 11 14:15:36
>> Closing as fixed.
>>
>> Current trunk (which will become Suversion 1.8) supports merging to-and-fro
>> between two branches, automatically performing the right sort of merge
>> (reintegrate or not, depending on which direction the previous full merge was)
>> to take all the not-yet-merged changes from the source branch to the target
>> branch.  The release-notes description is at
>> <http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge>.
>>
>> It is not perfect.  For one thing, it does not deal correctly with
>> revisions that have been cherry-pick merged between the branches
>> in all cases (it does in some cases).  However, it solves the basic
>> requirement.
>
> Hi Julian,
>
> Can we really call this fixed?  As you point out it does not deal with
> cherry pick (and subtree) merges in all cases.  Is there another issue
> for the aspects that still don't work?

Well, I admit it's a bit bold to call it fixed, but I looked at what the issue was asking for, and it's almost entirely about basic repeated syncs and full merging to-and-fro between a pair of branches.  Those merges were the reason for opening the issue, so I think it's fair to close it on those terms.

Of course we want to support cherry picks as well.  I think the best thing would be to open a new issue.  I don't think there is on, so I'll do that.

But if you feel this "Reflective merges are faulty" issue should stay open, we can re-open it.

> On a practical note, we have a test associated with this issue that is
> set to XFail:
>
> merge_tests.py 49 'avoid repeated merges for cyclic merging'

OK, I'll take a look at that.  Thanks.

- Julian
Received on 2013-04-12 19:39:35 CEST