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

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.

> This post-commit bumping of the SUBDIR revision and marking it as
> not-present is part of the commit processing. It should happen during
> the queue work, rather than a special pass. This bumping/marking is
> *required* by our mixed-rev design, and needs to stick around.

Agreed.

> Thus,
> it should be integrated into the database manipulation for the commit
> handling of SUBDIR.
>
> I'm saying: remove the special handling today, and do it as part of
> the normal commit process. Do that today, because we also need it
> tomorrow.

Perhaps. As part of the move to a singe db we have to make "ordinary"
directory deletion work without using the .svn directory in the
deleted directory. We might take advantage of the single db to do
this. When ordinary deletion works the special case code can simply
be deleted. Removing the special case code before single db might be
more complicated, or it might be a step along the way. It depends on
the details of the implementation.

-- 
Philip