On Fri, 2009-10-16 at 09:48 -0400, Greg Stein wrote:
> On Fri, Oct 16, 2009 at 09:08, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> > 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"? :-)
>
> I look at the trees kind of like overlays. You start with the BASE,
> then place WORKING "over" that, and then ACTUAL over that one. Where
> you haven't made a change in WORKING/ACTUAL, you simply see BASE.
>
> And yes, I realize that is imprecise :-P
>
> I used the term "base_shadowed" from a similar concept in C's variable
> scoping. That an inner block can "shadow" an outer block's variable.
>
> In the read_info() case, you're looking at information from the
> WORKING_NODE table, which is "shadowing" the BASE_NODE table. Or
> overlaying it. Or occluding it. Or override. Or whatever term you care
> to use.
OK, that's making sense. So here, "base_shadowed" means "the WORKING
tree has some kind of change for this node", which in turn means a
change of node kind or presence, or the node is replaced by one of the
same kind but a different identity.
> >> > 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.
>
> Euh... no. "not-present" nodes are NOT on disk.
Sorry, yes. (I was thinking of a WC-1 schedule-delete dir still being
present as a skeleton, but we're not talking about schedule-delete here
but rather a committed delete.)
> >> 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?
>
> The BASE node *is* there. Period. Its presence is labeled as
> "not-present", but that thing is there. And it is important that
> higher layers are well aware of that fact. Mixed revision working
> copies rely on not-present nodes.
>
> So... no. No monkeying around on changing the "base_shadowed" value
> depending upon the BASE node's presence value.
OK, I think I'm just converging on your definition of "the node is
there". I think your definition of "there" is something like "this node
shows up explicitly in the metadata trees", whereas when I use general
natural language I'm normally talking about the logical state of the
version-controlled resource.
That's fine. I'm not about to ask you to change the models, I'm just
learning how it is. Thanks for the explanations.
> >> > 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 :-)
>
> Right. svn_wc__db_base_get_info() returns a very small subset.
> read_info() a bit larger subset. But then you gotta turn to
> scan_addition() for refinement of an "add" status, or scan_deletion
> for a "delete" status.
OK. I know these are currently "private" APIs, and the WC-internal uses
of them are happy to care about these ... um, details.
Perhaps there's something we can take from this discussion and paste
into the docs?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408243
Received on 2009-10-16 16:30:31 CEST