You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@subversion.apache.org by "Stefan Hett (JIRA)" <ji...@apache.org> on 2017/11/22 14:31:00 UTC

[jira] [Assigned] (SVN-4649) file obstruction upon merge of an already merged added/moved file

     [ https://issues.apache.org/jira/browse/SVN-4649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Hett reassigned SVN-4649:
--------------------------------

    Assignee: Stefan Hett

> 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)