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 kind of think the latter, but if not-present nodes have no revision,
then this working copy would be JUST r9. But that isn't true either.
subdir is missing.
>> 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.
Yes. My gut says that our commit process needs to consider and handle
this case. Thus, to get our commit handling for wc-ng done, we need
the case relocated to that point (svn_wc__db_global_commit).
Single or multi-db... it doesn't feel like the coding will be any
different, but I do think that having it co-located will help
global_commit().
Cheers,
-g
Received on 2010-03-14 01:00:47 CET