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.
Received on 2014-02-06 12:23:32 CET