subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: svn commit: r918246 - /subversion/trunk/subversion/libsvn_wc/adm_ops.c
Date Tue, 02 Mar 2010 23:21:16 GMT
On Tue, Mar 2, 2010 at 18:09,  <cmpilato@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

Mime
View raw message