On Thu, Mar 11, 2010 at 06:46, Philip Martin <philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>...
>> ... and then calling the function on path/some-subdir. It will record
>> (in path/.svn/) that some-subdir is "not-present" in the working copy.
>>
>> The function is used as part of the commit code. Post-commit, we are
>> allowed to mark that subdir as "not-present" in the new revision of
>> path/... since we know it was deleted as part of the commit. We don't
>> mind that the subdir is missing because that recording is in the stub
>> located in path/.svn/
>>
>> 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?
My point is that this should be handled during the processing of the
queue, rather than a custom call before queue processing starts.
>> stashed away in the stub. We should be able to eliminate the function
>> today, and fold it into commit processing (and then it *may* further
>> simplify during the single-db move).
>
> 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.
Cheers,
-g
Received on 2010-03-11 20:32:05 CET