Stefan Küng <tortoise...@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
