Re: Irrevocably locked working copy after svn delete

Hi,

thank you very much for your detailed answer.

> Arguably, we could add a check of the on-disk state before we delete
> the file in meta data. But implications would have to be investigated
> first (whether to completely fail in the recursive delete case,
> whether this would hurt performance a lot, etc.).
Don't worry. This is most probably an edge case and does not affect many
users.
As you stated already we just have to make sure that the entries in the
working copy have read/write access.
After all we will have to and can live with it...

Thanks a lot for your time
Best regards,
Alexander Lüders

Am 06.02.2014 14:47, schrieb Stefan Sperling:
> On Thu, Feb 06, 2014 at 02:11:45PM +0100, Alexander Lüders wrote:
>> So after the failed svn delete a subsequent cleanup would try to finish the
>> unfinished delete?
> Well, here's how the mechanics work in some more detail:
>
> The deletion in meta data doesn't fail. It adds a base-deleted row
> for the file to the NODES table in wc.db and also adds a work queue
> item which will be run later to delete the on-disk file, once the entire
> deletion (which is possibly recursive in the general case) has been
> committed to wc.db. If this fails part of the way through for some
> reason, all meta-data changes are rolled back, and no change happens.
>
> It's the deletion of the on-disk file that is failing, when the work
> queue is run, after all related meta-data changes have been completed.
>
> 'svn cleanup' simply tries to run the work queue to get the working
> copy into a consistent state. It doesn't know how to undo completed
> meta data modifications.
>
>> 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.
> File modifications are not managed as part of the meta data.
> They are detected on the fly during the commit process by comparing
> file timestamps and sizes to values recorded in meta data during
> checkout/update, and even comparing file content if necessary.
>
>> I don't understand why it is necessary to retry the failed delete (keeping
>> it in the journal) at all.
> Because the operations is done in meta data first and then on disk.
>
> Arguably, we could add a check of the on-disk state before we delete
> the file in meta data. But implications would have to be investigated
> first (whether to completely fail in the recursive delete case,
> whether this would hurt performance a lot, etc.).

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