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

Johan Corveleyn commented on SVN-4680:
--------------------------------------

I can confirm this is an issue. Thanks for reporting it, and thanks for the 
reproduction script.

In general we prefer that new issues are first discussed on our 
users-mailinglist (as is clearly stated on 
http://subversion.apache.org/reporting-issues.html), which gives it more 
visibility, and opportunity for other users, administrators and svn-devs to 
analyse the issue and perhaps suggest workarounds. But okay, here we are now, I 
concur that this is an issue.

Whether this makes it a "bug" or simply a limitation of the current design ... 
I'm not so sure. It might be the latter, which will make it hard to fix.

Some extra data:
* I can reproduce with 1.8.17, 1.7.22, and with trunk@beginning-of-2017 (i.e. 
1.10-to-be).
* You can get the same issue with a "forward update" if you create the external 
in rev 2 with a peg revision. The "removal of externals" and "move of 
directory" can even be spread accross different revisions. If the 'svn update' 
spans both changes, you run into this problem. See below:

After checking out the empty working copy from newly created repository:
{noformat}
mkdir "%WCROOT%/dir1"
type nul > "%WCROOT%/dir1/file1.txt"
mkdir "%WCROOT%/dir2"
type nul > "%WCROOT%/dir2/file2.txt"

svn add "%WCROOT%/*.*"

svn ci "%WCROOT%" -m "rev1"

rem update to the head
svn up "%WCROOT%"

rem move /dir2 into /ext
mkdir "%WCROOT%/ext"
svn add  "%WCROOT%/ext"
svn mv "%WCROOT%/dir2" "%WCROOT%/ext"

svn pset svn:externals "^/ext/dir2@2 dir2" "%WCROOT%"

svn ci "%WCROOT%" -m "rev2"

rem update to the head
svn up "%WCROOT%"

rem delete externals definition
svn propdel svn:externals "%WCROOT%"
rem update so the externals change gets processed
svn up "%WCROOT%"

svn ci "%WCROOT%"  -mrev3
svn up "%WCROOT%"

svn mv "%WCROOT%/ext/dir2" "%WCROOT%"

svn ci "%WCROOT%"  -mrev4
svn up "%WCROOT%"

rem Now update back to rev 2 and again to HEAD (rev 4) -> obstruction
svn up -r2 "%WCROOT%"
svn up "%WCROOT%"
{noformat}

However, repeating the last update statement fixes it. So:

Workaround: execute the last update statement again, and the operation will be 
completed successfully.

> obstructing working copy after clean update to a revision
> ---------------------------------------------------------
>
>                 Key: SVN-4680
>                 URL: https://issues.apache.org/jira/browse/SVN-4680
>             Project: Subversion
>          Issue Type: Bug
>    Affects Versions: 1.9.5
>         Environment: windows 7 x64, tortoise svn tools
>            Reporter: Andrey
>              Labels: obstructing
>         Attachments: test_update_issue.bat
>
>
> If try to move some directory into new place and make external on the old 
> place of the moved directory with the same name, then the svn stops update 
> this external properly if execute backward update into revision below the 
> commit with new external.
> See the windows batch script in the attachment for reproduction.
> The output is:
> {quote}
> Checked out revision 0.
> svn: Skipping argument: E200025: 'test_repo_root/.svn' ends in a reserved name
> A         test_repo_root\dir1
> A         test_repo_root\dir1\file1.txt
> A         test_repo_root\dir2
> A         test_repo_root\dir2\file2.txt
> Adding         test_repo_root\dir1
> Adding         test_repo_root\dir1\file1.txt
> Adding         test_repo_root\dir2
> Adding         test_repo_root\dir2\file2.txt
> Transmitting file data ..done
> Committing transaction...
> Committed revision 1.
> Updating 'test_repo_root':
> At revision 1.
> A         test_repo_root\ext
> A         test_repo_root\ext\dir2
> D         test_repo_root\dir2
> D         test_repo_root\dir2\file2.txt
> property 'svn:externals' set on 'test_repo_root'
> Sending        test_repo_root
> Deleting       test_repo_root\dir2
> Adding         test_repo_root\ext
> Adding         test_repo_root\ext\dir2
> Committing transaction...
> Committed revision 2.
> Updating 'test_repo_root':
> Fetching external item into 'test_repo_root\dir2':
> A    test_repo_root\dir2\file2.txt
> Updated external to revision 2.
> At revision 2.
> Updating 'test_repo_root':
> D    test_repo_root\ext
> Skipped 'test_repo_root\dir2' -- An obstructing working copy was found
>  U   test_repo_root
> Removed external 'test_repo_root\dir2'
> Updated to revision 1.
> Summary of conflicts:
>   Skipped paths: 1
> {quote}
> I know this is old issue, but why a clean copy could not be so as clean 
> updated?
> Why the externals does not process for remove before the update to a 
> revision? If you do so this error would not happen.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

Reply via email to