Major The following comment was added in r38927: /* Issue #3281. * * Skip schedule-delete children inside of schedule-replace * directories. They cause an out-of-date error upon commit, * and prevent replaced directories from being committed. * * The out-of-date error happens because we recursively delete the * replaced directory in the transaction, then copy the replacing * directory in its place, and then try to delete nodes inside * the directory which existed only in its pre-replaced state. * The attempt to delete non-existent nodes from the transaction * (with node kind "none") is prevented by libsvn_repos/commit.c: * delete_entry() which sends the out-of-date error. * * ### We should not skip deletions which happened post-replace. * ### * ### This is not possible in wc-1 right now, because post-replace * ### deletions are not represented in working copy meta data. * ### Such nodes simply have NO entry at all in wc-1. The entry * ### gets blown away as part of deleting the apparently "locally * ### added" node, instead of changing the entry's schedule to * ### "delete". Note that replaced directories can only happen as * ### part of a set of local changes, either made manually or by a * ### merge. That's why nodes inside of replaced dirs are always * ### considered "locally added". The subtleties of the * ### locally-added-inside-of-a-replaced-parent-directory case are * ### wrongfully ignored during entry deletion. * ### * ### On top of that, libsvn_repos/commit.c:add_directory() will * ### always do server-side copies for directories added with * ### history, instead of copying the directory state verbatim * ### from the WC. This causes nodes which the user meant to delete * ### post-replace to show up in the commit transaction regardless. * ### This is not a problem in itself, but because there is no * ### entry for a post-replace deleted node, we cannot send a * ### separate deletion to remove the post-replace deleted node * ### from the transaction after the directory was copied on the * ### server. * ### Worse, the entry comes back only after an update which * ### explicitly targets the node which is now locally missing * ### but present on the server, in a revision the WC thinks it * ### has the entire state of! By not handling the * ### locally-added-inside-of-a-replaced-parent-directory entry * ### removal case properly, the client corrupts the WC meta data * ### without realising the mess it just made. * ### * ### So our ignorance about post-replace deleted nodes here is * ### just a side-effect of a much bigger problem, which has existed * ### for some time (at least since 1.5.x, probably much longer). * ### * ### WC-NG should fix all of this before 1.7 release. * ### Note that, in trunk, the entry of post-replace deleted nodes * ### does not get blown away, so trunk is one step ahead of 1.6.x * ### already. */