[
https://issues.apache.org/jira/browse/SVN-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16262600#comment-16262600
]
Stefan Hett edited comment on SVN-4649 at 11/24/17 11:19 AM:
-------------------------------------------------------------
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.
Also note that the "proper" way to resolve this would actually be to
copy_from-handling to add_file in repos_diff.c (see TODO marker with reference
to this issue). But since this is quite a complex thing, we're fine for now
with staying with triggering a tree conflict and have the conflict resolver
handle this via a recommended resolution.
was (Author: luke1410):
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)
