Branko Čibej <br...@e-reka.si> writes: > On 09.02.2011 18:54, phi...@apache.org wrote: >> Author: philip >> Date: Wed Feb 9 17:54:02 2011 >> New Revision: 1069001 >> >> URL: http://svn.apache.org/viewvc?rev=1069001&view=rev >> Log: >> The new revert is non-recursive in the database so remove the depth >> parameter. Allow actual-only revert. >> >> * subversion/libsvn_wc/wc_db.c >> (svn_wc__db_op_revert): Remove depth parameter, allow actual-only revert. > > Does this mean that, if you want to recursively revert a large working > copy, you'll have to use one sqlite query per changed file?
Perhaps, in the short term anyway. The current, broken, implementation is per-node. We need a non-recursive revert, revert is non-recursive by default, so that is what I am working on. A recursive revert can be implemented in terms of non-recursive, but not vice versa. A recursive revert in the database can be considered an optimisation and is probably easy to implement, apart from the notification problem. If one writes an SQL statement to remove all WORKING or ACTUAL nodes on some part of the working copy how does the notification callback get called for each local_relpath removed? Perhaps we first run a select to get the paths, then run delete, then return the list of paths to the caller? Even if we do write a recursive database operation revert will still need to crawl the working copy looking for text mods. -- Philip
