When excluding a subtree from the working copy, if any unversioned items are present then the svn update command fails silently, leaving the working copy locked and requiring cleanup.
This is with version 1.9.4, the current release. Reproducing the problem is fairly straightforward. Create a new repo (or just use an existing one): $ svnadmin create repo $ svn checkout file://`pwd`/repo wc Checked out revision 0. Add a directory and subdirectory: $ cd wc $ mkdir dir $ mkdir dir/subdir1 $ svn add dir A dir A dir/subdir1 $ svn commit -m "Added dir" Adding dir Adding dir/subdir1 Committing transaction... Committed revision 1. Create another subdirectory, without adding it to the repo: $ mkdir dir/subdir2 Now, let's exclude "dir" from the working copy: $ svn update --set-depth exclude dir D dir/subdir1 OK, so svn says it has deleted "dir/subdir1", but has left "dir" alone. Fair enough, as "dir" contains the unversioned item "subdir2". But wait - let's take a peek: $ ls dir subdir1 subdir2 Huh? What is "subdir1" still doing there? Let's quickly do a regular update: $ svn update svn: E155037: Previous operation has not finished; run 'cleanup' if it was interrupted Oooh, that's not good! Let's take a closer look: $ svn status L . L dir ? dir\subdir1 ? dir\subdir2 Yikes! Looks like svn bailed out without finishing the job. This must be a bug, right? Any chance somebody can take a look at it? Thanks!
