[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

API review - the 'commit_as_operations' flag on svn_client_commit5()

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Thu, 23 Jun 2011 11:37:00 +0100

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
Received on 2011-06-23 12:37:39 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.