On Fri, 2009-10-16 at 08:52 -0400, Greg Stein wrote:
> 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
> > arguments:
> >
> > /* 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)
> > svn_wc__db_base_get_info(&base_status,
> > 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).
Can you please try to explain "shadowed" precisely without using the
word "shadowed"? :-)
> > 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.
Yup, I get that: it's own state is logically "not present", and that
fact is recorded by explicit metadata rather than implicit by the lack
of a child name 'foo' in DIR. And (in per-dir .svn WCs) 'foo' also
exists physically on disk.
> If the node is "not present", then you're not replacing it. You're
> adding a node back into the repository.
Why don't you want the 'base_shadowed' indication to take account of the
logical state? As it is, it seems to me that the 'base_shadowed'
indication leaks information about the existence of a "virtual" 'foo' in
the implementation of metadata, because who cares whether the "I'm at
r15 and not present" metadata is stored in a "virtual" 'foo' or
implicitly?
> > 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.
Whoa, that's totally not obvious. It returns a status_t. I saw on IRC
you said "maybe I should update the doc string now"... +1 to that :-)
I can't go any further without it.
- Julian
> 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
> svn_wc__db_scan_addition().
>
> 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).
>
> Cheers,
> -g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408218
Received on 2009-10-16 15:08:22 CEST