Greg, I noticed there is a check in the filesystem editor implementation to ensure we have a valid revision during delete. Unfortunately, we don't always have such a revision a priori, which means this check is not always valid.
Consider the following: $ svn cp A B $ svn rm B/C $ svn ci In this case, we are legitimately deleting B/C, but the "revision this thing is being deleted from" doesn't exist until commit finalization. A more concrete example is in the form of op-depth test 14 where we do a copy, and then a move within that copy. This test currently fails on the ev2-export branch with this error: [[[ $ ./op-depth-test 14 subversion/tests/libsvn_wc/op-depth-test.c:1849: (apr_err=200004) subversion/libsvn_client/commit.c:1719: (apr_err=200004) subversion/libsvn_client/commit.c:849: (apr_err=200004) svn_tests: E200004: Commit failed (details follow): subversion/libsvn_client/commit.c:1648: (apr_err=200004) subversion/libsvn_client/commit_util.c:1763: (apr_err=200004) subversion/libsvn_client/commit_util.c:1728: (apr_err=200004) subversion/libsvn_client/commit_util.c:1566: (apr_err=200004) subversion/libsvn_delta/editor.c:758: (apr_err=200004) subversion/libsvn_repos/commit.c:1157: (apr_err=200004) subversion/libsvn_delta/editor.c:758: (apr_err=200004) subversion/libsvn_fs/editor.c:445: (apr_err=200004) svn_tests: E200004: Revision for deletion of '/X/B/C/F' is required FAIL: op-depth-test 14: test_delete_of_replace $ ]]] Simply eliminating the check in editor.c:delete_cb(), and also changing can_modify() to allow invalid revision to act as a wildcard (i.e., "don't bother checking, I know this should be modifiable") makes the test pass, but I don't know that that's the generally correct solution. There are similar test failures in other editor receivers that make the same check, and I think similar sorts of valid operations could cause them. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/
