Brian Denny <brian@briandenny.net> writes:
> 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'.
Sounds right to me! Assuming we reported the wc state correctly, we
have to trust the server... trust that it has accounted for all
deltas. Any "stragglers", such as missing or 'deleted' items, need to
be cleaned up.
---------------------------------------------------------------------
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:12:24 2003