Although the client will transmit the old "recursive=no" flag in both the
svn_depth_files and svn_depth_empty case, there is still no code on the client
side to deal with the unwanted data the server will send down (some files in the
"client wants svn_depth_empty but server only knows recursive=no" case, and both
some files and some empty directories in the "client wants depth_immediates but
server only knows recursive=no" case). This is the "legacy servers will send
back a bunch of information the client doesn't want" scenario described in the
'Implementation' section of notes/sparse-directories.txt. Even though
implementing it won't shorten the wall clock time of operations by much, it
would still make the client behave "correctly" (if slowly) even against old
servers. Therefore, it's still needed.
COMPLICATION: the editor vtable's delete_entry() function is path-kind ignorant,
which means that client-side editors trying to compensate for over-informative
server-side editor drivers don't have enough information to correctly
distinguish whether a deletion of an immediate child should be allowed to pass
thru when using svn_depth_files.
Bug
Major
SVN-2918 [sparse-directories] Optimize depth filtering (server compatibility) logic