I want to see if people are coolt with my planned solution to issue 919.
But first, here's a quick recap of the bug:
### start with a standard 'greek-tree' at r1
$ svn up -r0 iota
D iota
$ svn up
### nothing happens; iota never comes back.
The reason the bug happens is that iota's entry is removed
permanently, rather than marked as 'deleted'. This causes the
parent directory to lose track of its proper list of children; in
the second update, libsvn_wc erroneously tells the server it has a
complete copy of r1 of the directory... so the server does nothing.
We've solved this 'ghudson'-class bug before, but specifically in the
case of commits. When we commit a deletion, we mark the item as
'deleted' in parent (in post-commit-processing) IFF the item's revnum
is later than the parent.
But now it seems we need to do something similar in the update case.
So I've zoomed in on the libsvn_wc update_editor. This editor is very
much aware of the anchor/target situation. Thinking about it for a
while, it seems to be that bug 919 *only* happens in situations where
the update target is non-NULL (i.e. you're updating a specific child
within a versioned directory.) That's the only scenario in which the
child might be deleted, but the parent's revnum go unchanged.
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?)
[P.S. I also thought of a "sneaky but lazy" alternative
solution... instead of marking the child as 'deleted', we can mark the
parent as 'incomplete'. This guarantees the next update of the parent
will be one of the new 'low confidence' reports. Heck, we might even
be able to get rid of the *whole* 'deleted' flag this way!]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jun 20 00:34:28 2003