Philip Martin <philip@codematters.co.uk> writes:
> > So I think the delete_entry() function can grow some new logic: if the
> > thing being deleted *is* the target of the update, then we can have
> > its entry marked 'deleted'. Very simple.
> >
> > (Philip, does this sound right to you?)
>
> I was wondering if we could do it without any special case code: have
> delete_entry (or some low level function?) always mark the item
> 'deleted', then the existing code to remove 'deleted' flags would
> clean-up when the parent was updated.
Hmmm, well, it seems that in practice, my proposal isn't working
right. delete_entry() sees that (eb->target != NULL), so after
deleting the entry, it recreates a 'deleted' entry.
But then in close_edit(), we call svn_wc__do_update_cleanup() which
ultimately calls svn_wc__tweak_entry(), which decides to
*deliberately* remove all 'deleted' files. This logic was assuming
that the 'deleted' state could only happen in post-commit
processing... and that "if the server didn't overwrite it, then it
meant for the thing to be gone!"
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.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 01:45:18 2003