You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Stein <gs...@gmail.com> on 2009/10/16 02:49:42 UTC
your question about schedule_replace
Hey Stefan,
I saw on IRC that you asked about the equivalent for the old
schedule_replace. It isn't straight-forward, so you should use the
following function from questions.c:
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;
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408083
Re: your question about schedule_replace
Posted by Julian Foad <ju...@btopenworld.com>.
On Fri, 2009-10-16 at 09:48 -0400, Greg Stein wrote:
> On Fri, Oct 16, 2009 at 09:08, Julian Foad <ju...@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 <ju...@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
Re: your question about schedule_replace
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Oct 16, 2009 at 09:08, Julian Foad <ju...@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 <ju...@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
Re: your question about schedule_replace
Posted by Julian Foad <ju...@btopenworld.com>.
On Fri, 2009-10-16 at 08:52 -0400, Greg Stein wrote:
> On Fri, Oct 16, 2009 at 05:35, Julian Foad <ju...@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
Re: your question about schedule_replace
Posted by Greg Stein <gs...@gmail.com>.
On Fri, Oct 16, 2009 at 05:35, Julian Foad <ju...@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).
> 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
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=2408211
Re: your question about schedule_replace
Posted by Julian Foad <ju...@btopenworld.com>.
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".
What is the significance of "base_status != not_present"?
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".
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2408169