On Fri, Mar 12, 2010 at 05:08, Philip Martin <philip.martin_at_wandisco.com> wrote:
>...
> As I understand it when the subdir is marked not-present the revision
> doesn't matter. Obviously the revision field is present in the
> database but it's value has no meaning. I don't know why you think it
> should be necessary to "bump the revision". If it's not-present at
> revision 10, say, it's also not-present at revisions 6 and 23; it's
> not-present at any revision.
Not true.
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.
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.
The revision is quite necessary.
>...
>> It can/should go away now. Conceptually marking something not-present
>> must always remain. This is providing a special code path, rather than
>> making it part of the regular commit processing. We need that regular
>> path regardless, and for this special stuff to go away. This is
>> independent of many-db or single-db.
>
> At some point during centralisation we have to change the normal
> directory deletion to stop using the .svn directory in the deleted
> directory. Once that happens this special case code can simply be
> deleted from client/commit.c (we may be saying the same thing here).
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. 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.
Cheers,
-g
Received on 2010-03-12 11:33:18 CET