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

Re: Irrevocably locked working copy after svn delete

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 6 Feb 2014 12:22:50 +0100

On Thu, Feb 06, 2014 at 11:54:31AM +0100, Alexander Lüders wrote:
> Dear Subversion team,
> I want to file a bug report affecting the most recent released version 1.8.5.
> Whenever I issue asvn delete on a versioned file on which the subversion client does not have any access rights, the working copy is irrevocably locked until the file is deleted manually by other means.

> 12) cleanup fails with
> >svn: E720005: Can't set file 'G:\svnlog\wc\testfile' read-write: Zugriff verweigert

This is by design. Subversion must ensure that working copy meta data
and the on-disk state are kept in sync. The working copy has a work
queue that acts like a journal in the sense that it attempts to replay
any unfinished operations before allowing further operations on the
working copy. If deleting an on-disk file is impossible, then keeping
the meta data of a deleted file in sync with the on-disk state is impossible.

The only alternative behaviour I could think of is for svn to error
out right away if asked to operate on a file it cannot access.
However this isn't trivial to do in general because the file could
be somewhere deep within a directory tree and Subversion would have
to look for it before doing anything. It also wouldn't be much better
than the current behaviour, except perhaps that the error message would
be clearer (something like "svn: cannot operate on files with no access

Note that Subversion doesn't version permission bits beyond the 'x' bit
(the 'executable' bit on UNIX-like systems).
It doesn't really care about other permission bits, except that it tries
to preverse them when moving/copying files etc. You simply need to make
sure that files in the working copy are read/write.
Received on 2014-02-06 12:23:32 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.