cmpilato@collab.net writes:
> Don't change our reporter, and don't change the delta driver.
> Instead, after the update is completed (or perhaps during the update,
> wherever it's both safe and efficient to do so), check the working
> copy for items that *should* have been restored, but are instead still
> "missing". If no errors occurred in the update, you can deduce that
> those items are still missing because they also didn't exist in the
> update-to revision. In which case, you can just remove them from the
> working copy yourself.
Yes, Brian... sorry to be so silent on this issue. My original
response to you was based on a misunderstanding of my own, so I fear
that I only made you more confused. :-(
Mike's solution is the correct one: the libsvn_wc code which crawls
the wc and generates a report should remember every path that is
"missing" (i.e. the entry exists, but the actual object is gone).
Then, after the update completes, it should check to see if any of the
"missing" paths are *still* missing (i.e. they weren't restored by the
server)... if so, the entries should be permanently removed.
This is absolutely the way to go. No need for server-side changes.
We do something similar to this in another scenario, but I won't go
into detail about that here, lest we confuse things more. Let's just
say there's a good precedent for this solution. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 25 22:36:30 2003