On Fri, Oct 16, 2009 at 05:35, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Greg Stein wrote:
>> svn_error_t *
>> svn_wc__internal_is_replaced(svn_boolean_t *replaced,
>> svn_wc__db_t *db,
>> const char *local_abspath,
>> apr_pool_t *scratch_pool)
>> It is equivalent to the wc-1 concept of:
>> *replaced = entry->schedule == svn_wc_schedule_replace;
> Examining this function provides me with an opportunity to learn
> something more about WC-NG.
> Here's the bare bones, stripped of error handling, pools and extra NULL
> /* Equivalent to the old notion of "entry->schedule == schedule_replace"
> svn_wc__internal_is_replaced(svn_boolean_t *replaced,
> svn_wc__db_t *db,
> const char *local_abspath)
> svn_wc__db_status_t status;
> svn_boolean_t base_shadowed;
> svn_wc__db_status_t base_status;
> svn_wc__db_read_info(&status, &base_shadowed,
> db, local_abspath);
> if (base_shadowed)
> db, local_abspath);
> *replaced = ((status == svn_wc__db_status_added
> || status == svn_wc__db_status_obstructed_add)
> && base_shadowed
> && base_status != svn_wc__db_status_not_present);
> The main point seems to be the "base_shadowed" indication. I guess that
> means something like "scheduled for replacement".
base_shadowed means that you have a BASE node which is shadowed by an
operation in the WORKING tree (could be an add or a delete).
> What is the significance of "base_status != not_present"?
If you have a directory and its contents at r14, then delete DIR/foo
and commit DIR/foo, then the deletion is r15. The node DIR/foo is
marked as "not-present" and r15. The directory DIR is not touched (you
didn't refer to it in the commit), and remains at r14.
The key here is that DIR/foo cannot simply be removed -- r14 thinks it
should be there. So we record the concept "we know about this node,
but it isn't really here right now." This concept corresponds to the
entry->deleted flag in wc-1.
If the node is "not present", then you're not replacing it. You're
adding a node back into the repository.
> What is the significance of "status" being add or obstructed_add? I
> would have thought that, if any qualification were needed on top of
> "shadowed", it would be "added or copied-to or moved-to".
read_info() only returns "add" or "obstructed_add". It doesn't return
the refinements of copied or moved_here. You potentially need to look
at ancestor nodes to determine what is really happening to an "added"
node, and this is done by a further call to
obstructed_add means that the DIR/SUBDIR is not present on the disk or
it was replaced by a non-directory (and possibly that SUBDIR's
administrative area is missing).
Received on 2009-10-16 14:52:38 CEST