[
https://issues.apache.org/jira/browse/SVN-4847?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032852#comment-17032852
]
Stefan Sperling commented on SVN-4847:
--------------------------------------
See
https://issues.apache.org/jira/secure/attachment/12992950/merge-interleave-3.sh.txt
for a reproduction script by Daniel Dickison.
If the merge in Step 9 of that script is instead performed as follows, the
merge completes without conflicts:
{code}
${SVN} merge -r0:HEAD ${URL}/trunk wcb
{code}
> Automatic merge gets confused if merges are performed in parallel
> -----------------------------------------------------------------
>
> Key: SVN-4847
> URL: https://issues.apache.org/jira/browse/SVN-4847
> Project: Subversion
> Issue Type: Bug
> Components: libsvn_client
> Affects Versions: all
> Reporter: Stefan Sperling
> Priority: Major
> Attachments: merge-interleave-3.sh.txt
>
>
> The automatic merge heuristic will pick the wrong merge strategy if merges
> and commits are interleaved like this:
> 1. Create trunk and branch1
> 2. Commit an edit to file mu in trunk
> 3. Commit an edit to file iota in branch1
> 4. Merge trunk -> branch1
> 5. Merge branch1 -> trunk
> 6. Commit trunk
> 7. Commit branch1
> 8. Commit further edits to mu in trunk
> 9. Attempt to merge trunk into branch
> At step 9 Subversion performs a reintegrate merge which results in a spurious
> merge conflict. If a sync merge is forced instead the merge completes without
> conflicts. If there was a way to extend the heuristic to detect this case the
> merge conflict could be avoided.
> This problem was reported by Daniel Dickison and discussed in detail in the
> users@ list thread: "False conflict with interleaved merge commits":
> https://svn.haxx.se/users/archive-2020-02/0002.shtml
> https://svn.haxx.se/users/archive-2020-02/0004.shtml
> https://svn.haxx.se/users/archive-2020-02/0006.shtml
> https://svn.haxx.se/users/archive-2020-02/0007.shtml
--
This message was sent by Atlassian Jira
(v8.3.4#803005)