ACK
(That's the best I can offer at the moment. Digging self out of pile of
TODO items.)
Greg Stein wrote:
> On Tue, Mar 2, 2010 at 18:09, <cmpilato_at_apache.org> wrote:
>> ...
>> +++ subversion/trunk/subversion/libsvn_wc/adm_ops.c Tue Mar 2 23:09:53 2010
>> ...
>> @@ -854,15 +854,18 @@
>> }
>>
>> /* Handle "this dir" for states that need it done post-recursion. */
>> - SVN_ERR(svn_wc__get_entry(&entry, db, dir_abspath, FALSE,
>> - svn_node_dir, FALSE, iterpool, iterpool));
>> -
>> + SVN_ERR(svn_wc__db_read_info(&status, NULL, NULL, NULL, NULL, NULL, NULL,
>> + NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> + NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
>> + NULL, NULL,
>> + db, dir_abspath, iterpool, iterpool));
>> /* Uncommitted directories (schedule add) that are to be scheduled for
>> deletion are a special case, they don't need to be changed as they
>> will be removed from their parent's entry list.
>> The files and directories are left on the disk in this special
>> case, so KEEP_LOCAL doesn't need to be set either. */
>> - if (entry->schedule != svn_wc_schedule_add)
>> + if (!(status == svn_wc__db_status_added ||
>> + status == svn_wc__db_status_obstructed_add))
>> {
>> SVN_ERR(svn_wc__db_temp_op_delete(db, dir_abspath, iterpool));
>
> In the old way of doing thigns, if the schedule was
> svn_wc_schedule_replace, then wc_db is going to return
> svn_wc__db_status_added for that condition. There are other
> considerations for determining "was this a schedule_replace of a plain
> schedule_add?"
>
> I've gotta run to a lunch. But if you look at
> questions.c::internal_is_replaced(), then you'll see that determining
> schedule_replace is a difficult problem. And the original
> schedule!=add condition *may* be looking for schedule_replace.
>
> But that is maybe the trick here, and why your testing did not find
> the code. Maybe it is only possible to see
> schedule_(normal|add|delete), and never a replace? That may narrow the
> amount of querying needed against wc_db. I can't take a look right
> now, but the comments suggest there may be very restricted conditions
> here.
>
> Cheers,
> -g
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-03-04 17:27:55 CET