Re: svn commit: r1069001 - in /subversion/trunk/subversion: libsvn_wc/wc_db.c libsvn_wc/wc_db.h tests/libsvn_wc/op-depth-test.c

Branko Čibej <brane_at_e-reka.si> writes:

> On 09.02.2011 18:54, philip_at_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