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 permission"). 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.
