[ 
https://issues.apache.org/jira/browse/SVN-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262600#comment-16262600
 ] 

Stefan Hett commented on SVN-4649:
----------------------------------

Reviewing the design shows that the behavior is expected. The tree conflict 
detection correctly detects and reports the obstruction of the added file. SVN 
1.10 should be able to take care about this scenario then via its conflict 
resolver.

> file obstruction upon merge of an already merged added/moved file
> -----------------------------------------------------------------
>
>                 Key: SVN-4649
>                 URL: https://issues.apache.org/jira/browse/SVN-4649
>             Project: Subversion
>          Issue Type: Bug
>    Affects Versions: 1.8.14, 1.8.19, 1.9.0, 1.9.7
>         Environment: Windows 10 (64-bit - build 1115)
>            Reporter: Stefan Hett
>            Assignee: Stefan Hett
>         Attachments: test_obstruction.bat, test_obstruction_min.bat
>
>
> The attached repro script demonstrates a case where a cherry-pick merge 
> produces the following error:
> "local file obstruction, incoming file add upon merge"
> Steps to reproduce:
> Run the attached repro script: test_obstruction.bat
> Actual result:
> svn merge file:///D:/testRepo/branches/testBranch trunk -c7 causes the error 
> (output with 1.9.4): "local file obstruction, incoming file add upon merge"
> Expected result:
> Merges without problem
> This is unexpected IMO, since all the merge does is merge back the 
> addition/renaming of a file which was merged before from trunk.
> Notes:
> - The repro script creates a test repo/wc on drive D.
> - The issue is not reproducible when not using a cherry pick merge (aka: 
> doesn't happen when setting the operative revision via @ and also doesn't 
> happen when doing a complete merge (aka: neither specifying a revision, nor 
> an operative revision)).
> - test_obstruction_min.bat is a reduced variation of the original test case, 
> triggering the same behavior without a rename operation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to