You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ph...@apache.org on 2010/10/08 11:53:19 UTC
svn commit: r1005751 - /subversion/trunk/notes/wc-ng/nodes
Author: philip
Date: Fri Oct 8 09:53:19 2010
New Revision: 1005751
URL: http://svn.apache.org/viewvc?rev=1005751&view=rev
Log:
* notes/wc-ng/nodes: server overwrite
Modified:
subversion/trunk/notes/wc-ng/nodes
Modified: subversion/trunk/notes/wc-ng/nodes
URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/nodes?rev=1005751&r1=1005750&r2=1005751&view=diff
==============================================================================
--- subversion/trunk/notes/wc-ng/nodes (original)
+++ subversion/trunk/notes/wc-ng/nodes Fri Oct 8 09:53:19 2010
@@ -217,6 +217,18 @@ become an op_depth layer of their own.
allowed to exist (ie. we have implied overwrite semantics in the
repository).
+ PM: Yes, we have overwrite sematics. The FS layer on the server has
+ magic that converts the copy of the r12 descendant into a replace if
+ the descendant exists in r10. The client does not send a delete.
+
+ This magic applies to copies, not deletes, so there is a problem
+ when the descendant is deleted in the mixed-revision copy in the
+ working copy. When faced with a copy of the subtree at r10 and a
+ delete of a descendant at r12 the commit doesn't work at present.
+ Deleting the descendant is wrong if it does not exist in r10, but
+ not deleting it is wrong if it does exist. I suppose the client
+ could ask the server, or perhaps use multiple layers of BASE to
+ track mixed-revisions (argh!).
In a deleted subtree, all nodes get marked deleted explicitly
-------------------------------------------------------------
Re: svn commit: r1005751 - /subversion/trunk/notes/wc-ng/nodes
Posted by Greg Stein <gs...@gmail.com>.
Can the client issue a delete, and continue if there is a failure?
And more importantly, if the server issues a failure, will it continue
to accept further changes?
IOW, can we send a delete (when we have no definitive knowledge),
ignore failures, and continue processing. Will the overall system
function?
Thx,
-g
On Fri, Oct 8, 2010 at 05:53, <ph...@apache.org> wrote:
> Author: philip
> Date: Fri Oct 8 09:53:19 2010
> New Revision: 1005751
>
> URL: http://svn.apache.org/viewvc?rev=1005751&view=rev
> Log:
> * notes/wc-ng/nodes: server overwrite
>
> Modified:
> subversion/trunk/notes/wc-ng/nodes
>
> Modified: subversion/trunk/notes/wc-ng/nodes
> URL: http://svn.apache.org/viewvc/subversion/trunk/notes/wc-ng/nodes?rev=1005751&r1=1005750&r2=1005751&view=diff
> ==============================================================================
> --- subversion/trunk/notes/wc-ng/nodes (original)
> +++ subversion/trunk/notes/wc-ng/nodes Fri Oct 8 09:53:19 2010
> @@ -217,6 +217,18 @@ become an op_depth layer of their own.
> allowed to exist (ie. we have implied overwrite semantics in the
> repository).
>
> + PM: Yes, we have overwrite sematics. The FS layer on the server has
> + magic that converts the copy of the r12 descendant into a replace if
> + the descendant exists in r10. The client does not send a delete.
> +
> + This magic applies to copies, not deletes, so there is a problem
> + when the descendant is deleted in the mixed-revision copy in the
> + working copy. When faced with a copy of the subtree at r10 and a
> + delete of a descendant at r12 the commit doesn't work at present.
> + Deleting the descendant is wrong if it does not exist in r10, but
> + not deleting it is wrong if it does exist. I suppose the client
> + could ask the server, or perhaps use multiple layers of BASE to
> + track mixed-revisions (argh!).
>
> In a deleted subtree, all nodes get marked deleted explicitly
> -------------------------------------------------------------
>
>
>
Splitting op_depth into base_op_depth and work_op_depth
Posted by Philip Martin <ph...@wandisco.com>.
philip@apache.org writes:
> Author: philip
> Date: Fri Oct 8 09:53:19 2010
> New Revision: 1005751
> + PM: Yes, we have overwrite sematics. The FS layer on the server has
> + magic that converts the copy of the r12 descendant into a replace if
> + the descendant exists in r10. The client does not send a delete.
> +
> + This magic applies to copies, not deletes, so there is a problem
> + when the descendant is deleted in the mixed-revision copy in the
> + working copy. When faced with a copy of the subtree at r10 and a
> + delete of a descendant at r12 the commit doesn't work at present.
> + Deleting the descendant is wrong if it does not exist in r10, but
> + not deleting it is wrong if it does exist. I suppose the client
> + could ask the server, or perhaps use multiple layers of BASE to
> + track mixed-revisions (argh!).
Suppose we were to split NODES.op_depth into base_op_depth and
work_op_depth, one of which is always set and one of which is always
NULL. Then we could represent a mixed revision working copy as a
layering of base_op_depth. (work_op_depth=0 might be allowed but
otherwise work_op_depth would be much like op_depth>0.)
Having layers of base_op_depth would allow us to represent a mixed-rev
copy as layers of work_op_depth and so should solve the delete problem
above. We could also used layers of base_op_depth to represent
switched subtrees, and that would probably allow us to handle deletes
of the root of the switch (as a tree conflict perhaps?). Layers of
base_op_depth would also allow us to represent externals as single
working copy: a base_op_depth=1 without base_op_depth=0 would be an
external.
This is probably not something for 1.7, I'd really like to get 1.7
released rather than spend forever redesigning it, but perhaps this is
something for 1.8?
--
Philip