svn commit: r1022597 - /subversion/trunk/notes/wc-ng/copying

[ju...@apache.org]

Author: julianfoad
Date: Thu Oct 14 16:14:53 2010
New Revision: 1022597

URL: http://svn.apache.org/viewvc?rev=1022597&view=rev
Log:
* notes/wc-ng/copying
  Add notes about copying a not-present child.

Modified:
    subversion/trunk/notes/wc-ng/copying

Modified: subversion/trunk/notes/wc-ng/copying
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/copying?rev=1022597&r1=1022596&r2=1022597&view=diff
==============================================================================
--- subversion/trunk/notes/wc-ng/copying (original)
+++ subversion/trunk/notes/wc-ng/copying Thu Oct 14 16:14:53 2010
@@ -71,13 +71,26 @@ revision source and from a source with a
 child.  In both cases the commit must either add or replace the child
 and if the copy is from a source that is locally added or replaced the
 client can make the distinction and send a delete before adding the
-replacement.  For a mixed revision the client doesn't distinguish
+replacement.  For a mixed revision, as the client doesn't know whether
+the child existed in its parent's revision and so can't distinguish
 between add and replace, it always sends an add and the FS layer
 converts to a replace as required (for details see 2010-04-19 comments
 in issue 3314).  We will probably have to continue rely on this in
 WC-NG as there is not enough information in the source to determine
 whether or not the child also exists in the parent's revision.
 
+If the mixed-rev source has a "not-present" child (effectively the
+same as "updated to r0"), then the copy schedules this as "delete".
+The client doesn't know whether the child existed in its parent's
+revision, so it can't distinguish between delete and no-op, so it
+always sends a delete.
+
+  ### This current fails, in both 1.6 and trunk.
+
+  ### TODO: The server needs to silently elide a delete, or the client
+  needs to detect the error and recover from it and continue if that
+  is possible.
+
 Child nodes not-present in the source become not-present working nodes
 in the copy, this ensures that they get deleted by the commit.  We
 might want to use a new not-copied state instead, since these deletes