rhuij...@apache.org writes: > This change also slightly changes the behavior of delete and revert on > children of a copy operation as it allows you to revert the separate commands > that will be performed on commit.
I suppose revert removes the higher op-depth child leaving the not-present child at the parent's op-depth. But that not-present still counts as deleted and will generate a delete on commit. It's not really new behaviour, with the old model it was possible to delete the mixed-rev child (creating a new base-deleted layer) and get the same behaviour. What is different is that in the old model one could revert the delete and go back to the mixed-rev child being present, in the new model it is not possible to revert. When the mixed-rev child is deleted (either as not-present in the new model or base-deleted in the old) one runs into the problem of copy_tests.py 89, mixed_rev_copy_del, that the client doesn't know whether or not to send the delete. > On top of that this commit will finally allow the commit processing to use > depth handling. Not sure what you mean by "depth handling" but commit is still going to have to detect the not-present child at the same op-depth as the parent and generate a delete if there is no higher op-depth for the child. -- Philip
