[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r921445 - in /subversion/trunk/subversion: include/private/svn_wc_private.h include/svn_wc.h libsvn_client/commit.c libsvn_wc/entries.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Sun, 14 Mar 2010 10:52:17 +0100

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.

Received on 2010-03-14 10:52:48 CET

This is an archived mail posted to the Subversion Dev mailing list.