Hi, After some research on an AnkhSVN issue I discovered the issue that I documented last weekend as issue #3659.
Since Subversion 1.5 added depth support on the update handler, we have a bug where a working copy thinks it knows all entries of a directory, but where the repository knows more entries. Future updates don't retrieve these entries and in many cases error out on non existing files. Let's assume I have a repository with a subdirectory. $ svn up wc/subdir <snip> Updated to r70. <Day later> # Fetch only the new properties on that subdirectory $ svn up --depth empty wc/subdir <snip> Updated to r80. <Day later> $ svn up wc <snip> Updated to r90. And now your working copy doesn't show the new files and directories you colleagues *added* in r71-r80. The reason we miss these additions is that our update process identifies the working copy state by the revision of the parent and possibly specific revisions of the children. (And some other details like depth, etc.). But in this case we updated the parent, but not its child-list. So the workingcopy description of the parent is incomplete and the repository doesn't know that it does send the new information. In a few other cases of mixed revision working copies, we applied specific fixes. * Delete operations that are committed leave a 'deleted' entry (WC-NG: not-present marking in BASE) * If an update fails halfway we keep the directory in an incomplete state * If a directories ambient depth is less than infinity, this is communicated in a special way to the server. But, this specific case here falls right through all these features. Only the repository knows about the additions (as the update is driven with a smaller depth), but the repository doesn't get a request for them. This is a pretty fundamental issue, that touches the original design of sparse working copies. And when the UI of the feature was discussed in 2007 there was some talk about some of these cases, but this issue was not found. http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=926 233 It will be pretty hard to resolve this issue while keeping the current non-recursive update behavior. I see a few options to resolve this: (<smaller> is a depth smaller than the ambient depth) * On 'svn up --depth <smaller>' store a new boolean on the directory to indicate that its child-list is incomplete. * On 'svn up --depth <smaller>' actually perform a depth a bit deeper and add deleted entries for the missed nodes. (WC-NG: BASE not-present nodes) * On 'svn up --depth <smaller>' set the ambient depth to '<smaller>' but keep the existing entries. (Recoverable via --set-depth infinity in the next update) * Deny 'svn up --depth <smaller>' Note that all this doesn't apply to the --set-depth options as these keep the ambient value [For the next AnkhSVN release we will be implementing the 'deny svn up --depth <smaller>' on the client layer, but I think this issue should be fixed in Subversion for a future version.] Bert
