Re: hosed working copy after interrupted rename

Stefan Küng <tortoisesvn_at_gmail.com> writes:

> Stumbled upon the following problem with 1.7.1+ (latest 1.7.x branch):
>
> $ svn co http://tvserver/svn/Test/trunk/TortoiseSVN/Languages renametest
> $ cd renametest
> - now open another console window in subfolder 'de' (so that the
> folder is locked and can't be removed)
> $ svn mv de de2
> A de2
> svn: E720032: Can't move '.....de' to '....de2': The process cannot
> access the file because it is being used by another process.

Where does the code fail? Is it inside the svn_io_file_rename call in
svn_wc_move?

> After that, the folder 'de2' is marked as 'missing' when doing an 'svn
> st'. Reverting or updating 'restores' that folder, marked as
> normal'. But since there was never a commit with that name, the folder
> de2' is now marked in the wc as if it is in the repository.

Why does revert restore de2? It's a copy, revert should revove it. If
I try to reproduce by interrupting a mv on Linux:

$ svnadmin create repo
$ svn mkdir -mm --parents file://`pwd`/repo/A/B
$ svn mv wc/A wc/X # interrupt at svn_io_file_rename
$ sqlite3 wc/.svn/wc.db "select op_depth, local_relpath, presence, revision from nodes"
0|A/B|normal|1
0|A|normal|1
0||normal|1
1|X|normal|1
1|X/B|normal|1

Running "svn revert -R wc/X" removes the X rows as expected.

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com