Brian Denny <brian@briandenny.net> writes:
> cool. i'd like to make sure i understand what the essential difference
> is between this idea and my original idea #2 (in which i was going to
> change recursively_tweak_entries to check for missing paths and delete
> their entries -- i posted a patch in the other thread.)
>
> is it that recursively_tweak_entries is too general-purpose, and might
> get called at times other than at the end of a successful update?
Hmm, maybe your proposal was exactly the same. Does anything call
recursively_tweak_entries() other than 'svn up' and 'svn switch'?
I don't think so...
> > 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. :-)
>
> if you really think it would confuse things, i'll trust your judgment on
> that; but i am kinda curious. :)
You asked for it. :-)
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.
(On the other hand, the server may have decided to add a *different*
file by the same name. That's fine too -- the 'deleted' entry would
just get overwritten by the new file's entry.)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 25 23:42:09 2003