Can I have a second pair of eyes on this please? When copy_tests.py 94
deletes a WC directory 'A/B' and tries to copy the repos file 'iota' to
WC path 'A/B', it the svn_wc_add_repos_file4() call fails with:
.../libsvn_client/copy.c:1570: (apr_err=155005)
.../libsvn_wc/update_editor.c:5572: (apr_err=155005)
.../libsvn_wc/lock.c:1468: (apr_err=155005)
svn: No write-lock in '.../copy_tests-94/A'
I don't understand why svn_wc_add_repos_file4() requires this parent to
be locked, while seven other code paths succeed:
WC-to-WC copies: (file/dir) over (file/dir)
repos-to-WC copy: file over file
repos-to-WC copy: dir over dir
repos-to-WC copy: dir over file
The following patch fixes it, but I'm not satisfied it's the correct
fix:
[[[
Fix a problem in copying a repository file over a deleted WC directory.
* subversion/libsvn_client/copy.c
(repos_to_wc_copy): Get a write lock on the target path's anchor, not just
on the target path itself.
* subversion/tests/cmdline/copy_tests.py
(test_list): Remove 'XFail' from copy_repos_over_deleted_other_kind.
--This line, and those below, will be ignored--
Index: subversion/libsvn_client/copy.c
===================================================================
--- subversion/libsvn_client/copy.c (revision 1031400)
+++ subversion/libsvn_client/copy.c (working copy)
@@ -1890,7 +1890,7 @@ repos_to_wc_copy(const apr_array_header_
SVN_ERR(svn_wc__call_with_write_lock(repos_to_wc_copy_cb, &baton,
ctx->wc_ctx, lock_abspath,
- FALSE, pool, pool));
+ TRUE, pool, pool));
return SVN_NO_ERROR;
}
Index: subversion/tests/cmdline/copy_tests.py
===================================================================
--- subversion/tests/cmdline/copy_tests.py (revision 1031411)
+++ subversion/tests/cmdline/copy_tests.py (working copy)
@@ -5017,7 +5017,7 @@ test_list = [ None,
XFail(copy_delete_revert),
delete_replace_delete,
copy_repos_over_deleted_same_kind,
- XFail(copy_repos_over_deleted_other_kind),
+ copy_repos_over_deleted_other_kind,
copy_wc_over_deleted_same_kind,
copy_wc_over_deleted_other_kind,
]
]]]
- Julian
Received on 2010-11-05 04:27:26 CET