Re: Irrevocably locked working copy after svn delete

Hi,

thanks for your quick response.

> Subversion must ensure that working copy meta data
> and the on-disk state are kept in sync.

I totally agree.

> 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.
So after the failed svn delete a subsequent cleanup would try to finish
the unfinished delete?
I just wonder why it's different for a svn commit of a versioned
modified file. Applying the same access restrictions on a modified file
do not result in a "locked" working copy after a failed commit. I.e. the
commit fails and no cleanup is necessary to retry the unfinished commit,
which eventually would fail again.
I don't understand why it is necessary to retry the failed delete
(keeping it in the journal) at all.

> You simply need to make
> sure that files in the working copy are read/write.

I did not know that yet.

Many thanks
Best regards,
Alexander Lüders

Am 06.02.2014 12:22, schrieb Stefan Sperling:
> 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.

-- 
Entimo AG
Stralauer Platz 33 - 34 | 10243 Berlin | Germany
Tel: +49.30.52 00 24 131 | Fax: +49.30.52 00 24 101
alu@entimo.com | http://www.entimo.com/
Vorstand: Jürgen Spieler (Vors.), Marianne Neumann
Aufsichtratsvorsitzender: Erika Tannenbaum
Sitz der Gesellschaft: Berlin, Germany | Handelsregister: HRB Berlin-Charlottenburg 85073