[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-issues
Subject:    [Issue 3468] New - children of replaced directories cannot be
From:       Stefan Sperling <stsp () elego ! de>
Date:       2009-08-25 13:35:16
Message-ID: iz3468 () subversion ! tigris ! org
[Download RAW message or body]

http://subversion.tigris.org/issues/show_bug.cgi?id=3468
                 Issue #|3468
                 Summary|children of replaced directories cannot be deleted pos
                        |t-replace
               Component|subversion
                 Version|trunk
                Platform|All
                     URL|
              OS/Version|All
                  Status|NEW
       Status whiteboard|
                Keywords|
              Resolution|
              Issue type|DEFECT
                Priority|P3
            Subcomponent|unknown
             Assigned to|issues@subversion
             Reported by|stsp






------- Additional comments from stsp@tigris.org Tue Aug 25 06:35:15 -0700 2009 -------
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. */

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=463&dsMessageId=2387081

To unsubscribe from this discussion, e-mail: [issues-unsubscribe@subversion.tigris.org].
[prev in list] [next in list] [prev in thread] [next in thread]