I'd like to understand the new 'commit_as_operations' flag on svn_client_commit5() a bit better. First, note that the old commit4() API passes FALSE. The doc string says:
* If @a commit_as_operations is set to FALSE, when a copy is committed * all changes below the copy are always committed at the same time * (independent of the value of @a depth). If @a commit_as_operations is * #TRUE, changes to descendants are only committed if they are itself * included via @a depth and targets. * * When @a commit_as_operations is #TRUE it is possible to delete a node and * all its descendants by selecting just the root of the deletion. If it is * set to #FALSE this will raise an error. So the commit_as_operations flag tells Subversion to commit a copy or delete of a directory as a tree operation, without the caller having to specify the children of the tree (individually or by setting 'depth' to a big enough depth). The implementation does two things with this flag. It suppresses a check for deleting a directory with insufficient depth specified; and it suppresses passing "recurse=TRUE" to svn_wc_queue_committed3(), which it would otherwise do when queueing a copied directory. The check for delete is all that's necessary for delete. But for copy, the recurse=TRUE only applies to post-processing the WC after the commit, so how does this affect what gets committed? It doesn't seem to pass the flag to _harvest_committables() or svn_client__do_commit() or anything before the post-processing. What am I missing? - Julian
