On Sun, Mar 14, 2010 at 1:00 AM, Greg Stein <gstein_at_gmail.com> wrote:
> On Fri, Mar 12, 2010 at 06:28, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> Greg Stein <gstein_at_gmail.com> writes:
>>
>>> The SUBDIR is a child of DIR in r9, and presumably also r6. When the
>>> commit is performed, constructing r10, SUBDIR is deleted. The working
>>> copy lists DIR at r9 which is *supposed* to include SUBDIR. Yet, due
>>> to mixed-rev working copies, we have SUBDIR at r10 which does not
>>> exist. It is therefore labeled as not-present.
>>
>> I disagree with "we have SUBDIR at r10". We expect SUBDIR at r9 but
>> the SUBDIR is not-present, its revision doesn't have a meaning.
>>
>>> By r23, it is possible for SUBDIR to return.
>>>
>>> If the parent is updated to r10, then the not-present SUBDIR can be
>>> removed because DIR_at_10 does not list SUBDIR as a child.
>>
>> I think not-present nodes get removed on update irrespective of
>> revision.
>>
>>> The revision is quite necessary.
>>
>> All that you have written just requires SUBDIR not-present, it doesn't
>> require r10.
>>
>> Suppose the commit that deletes SUBDIR is r11 and the parent is r9.
>> When the parent gets updated, be it to r9, r10, r11 or r12 the
>> not-present node gets removed (and possibly replaced by a normal
>> node). The r11 revision doesn't matter.
>
> .... yeah, I think I agree with all this. Thanks for the insight. I
> spent some time pondering on it today, and started to wonder whether
> this applies to "excluded" and "absent" nodes, too (all three are
> basically "the node isn't really there").
>
> However, a node could be absent in a specific revision, yet available
> for other revs. (e.g. administratively hide the one rev which has a
> password in it)
>
> Excluded doesn't really need a revision. "Whatever it is, this node is
> being kept out of the working copy." We can't just wipe them before an
> update (like the not-present nodes) because the concept is sticky.
>
> I'm not entirely sure we should be removing not-present nodes before
> an update (conceptually). There may be a better design that results in
> the same thing, but from a better/cleaner direction.
>
> Lastly... we may want to enforce this notion of "no revision", and
> have base_get_info() and read_info() return SVN_INVALID_REVNUM for
> not-present nodes (and excluded nodes).
>
> Then again, I think of Daniel's work on revision_status() lately. If I do:
>
> $ svn rm path/subdir
> $ svn commit path/subdir
> $ svnversion
>
> Should it report "just r9", or should it report "r9-10" ?
I think it should report r9-10 (as it is not a clean r9), but it most
likely did report just r9 <= 1.6, because it just skipped hidden
entries via the status walker.
update_editor.c's implementation of editor-v1.0 uses the revisions of
not-present nodes as an indicator which can be removed after an update
and which can't. (To support depth limited updating and a few other
things I can't remember without reviewing the code again).
not present nodes are send to the editor reporter as deleted (see
adm_crawler.c) to make them come in as changes if something does exist
there. (This reporting doesn't use a revision). If nothing comes in
(determined as: is the revision not equal to the target revision) the
not present node is removed on a successful close of the directory.
Bert
Received on 2010-03-14 10:52:48 CET