[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: hosed working copy after interrupted rename

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Mon, 21 Nov 2011 18:56:43 +0000

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

> 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"

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

uberSVN: Apache Subversion Made Easy
Received on 2011-11-21 19:57:24 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.