Re: issue 919 solution

Ben Collins-Sussman <sussman@collab.net> writes:

> So I think your approach will work better, Philip:
>
> 1. have delete_entry() mark the entry 'deleted' no matter what, and
> attach the update's target_revnum to it.
>
> 2. have the cleanup code (tweak_entry()) compare revnums. If the
> 'deleted' entry revnum is the same as the parent, then it's safe
> to remove the entry altogether (i.e. the delete was part of
> updating the parent, not an action on an isolated target.)

Nope, this doesn't work either. We're really screwed here.

Suppose we're in the post-update processing, happily bumping working
revs. We see a 'deleted' entry with a revnum lower than its parent's
revnum.

What does it mean?

1. The 'deleted' entry might have been created long ago in post-commit
   situation. That would indicate it's time to remove deleted child
   forever. (The user updated to HEAD, and server thought it was
   supposed to be gone, so it didn't say anything).

2. The 'deleted' entry might have been created in our backdate-a-file
   scenario. So of course the deleted child still has a lower revnum
   than its parent; but in this case, we want the deleted child to
   *stay*, to ensure better more accurate reports to the server.

It's starting to look like we need to add another entry flag, one
which indicates the history/purpose of the 'deleted' entry.

I think I may go mad...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 02:10:41 2003