On Fri, Apr 25, 2003 at 04:40:32PM -0500, Ben Collins-Sussman wrote:
> If you schedule a file for deletion and then commit, guess what? The
> file's entry isn't really gone yet. It's marked as "deleted" --
> past-tense. Why? For update reporting. When reporting wc state to
> the server, the parent dir claims to be at revision N, but really,
> it's a lie, because rev N of the directory includes the deleted file.
> (The file was deleted in rev N+1). Thus the reporter has to notice
> the 'deleted' entry and report it as missing. The server does a diff,
> sees no difference between the txn and rev N+1, and sends no changes.
>
> Now we get into post-update processing. The directory is bumped to
> working revision N+1. If the server never mentioned the deleted file,
> then heck, it *should* be gone for good, so we remove the 'deleted'
> entry permanently.
so, if i am thinking straight:
after a successful update, there should be no "missing" items and
no "deleted" items -- for every entry, a file or directory should
exist. therefore, in [wherever the post-update processing you refer
to above happens], we can delete *any* entry whose corresponding
file or directory does not exist on disk, whether or not it is marked
'deleted'.
does that sound right to you?
-brian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 26 00:07:51 2003