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.
>> > 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.
>> 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.
>> > 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.
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408231
Received on 2009-10-16 15:48:36 CEST