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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 23 Jun 2011 13:33:25 +0200

> -----Original Message-----
> From: Julian Foad [mailto:julian.foad_at_wandisco.com]
> Sent: donderdag 23 juni 2011 12:37
> To: Subversion Development
> Subject: API review - the 'commit_as_operations' flag on
> svn_client_commit5()
> 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.

If you commit a copy passing FALSE (and depth < infinity) will commit all text (and other) changes in descendants of the copy, like how we handled commit in 1.6.

If you pass TRUE (and depth < infinity) only the changes in selected descendants will be committed.

So assuming --depth empty and only the root of a copy passed as argument:
* With TRUE: The copy is committed and local modifications of descendants are left as modifications for a future commit. (WC-NG status changes from ADD to Modified. Normal status From M+ to M)
* With FALSE: all changes in descendants are committed together with the parent. (Everything goes to status normal).

In 1.6 you couldn't commit directory deletions with DEPTH < infinity, but now we can assume a depth infinity lock on the wc and as a delete is always recursive we/I removed this old limitation.

(These limitations aren't commonly visible with 'svn' where you usually commit with depth infinity. But GUIs like TortoiseSVN, AnkhSVN and Subclipse show checkboxlists for committing where this really makes a difference)

Received on 2011-06-23 13:33:56 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.