On Tue, Mar 2, 2010 at 18:09, <cmpil...@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
