Jim Barry created SVN-4642:
------------------------------
Summary: "svn update --set-depth=exclude" exits prematurely,
leaving repo in need of cleanup
Key: SVN-4642
URL: https://issues.apache.org/jira/browse/SVN-4642
Project: Subversion
Issue Type: Bug
Affects Versions: 1.9.4
Reporter: Jim Barry
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 (it works fine with 1.8.16).
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 message was sent by Atlassian JIRA
(v6.3.4#6332)
