Greg Stein <gstein_at_gmail.com> writes:
> On Thu, Mar 11, 2010 at 06:46, Philip Martin <philip.martin_at_wandisco.com> wrote:
>> Greg Stein <gstein_at_gmail.com> writes:
>>...
>>> That said, the function is bogus because this kind of recording should
>>> happen during commit processing naturally. And it should bump the
>>> revision on that directory, rather than just alter the presence value
>>
>> Which revision/directory? The deleted directory doesn't have a
>> revision any more and the parent might not be changing.
>
> *Especially* if the parent is not changing. If the parent remains at
> r9 (which includes the subdir), and you commit the deleted subdir (in
> r10), then the subdir is marked as not-present @ r10. That is what
> this function does, right?
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.
>> Once we have a singe-db then this sort of deleted directory stops
>> being special, it's just a normal deleted directory. We will have to
>> keep the function because it's part of the public API.
>
> 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).
--
Philip
Received on 2010-03-12 11:09:29 CET