On 2/6/14, 5:47 AM, Stefan Sperling wrote:
> 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, et
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,
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
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 furthe
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 wor
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 othe
6 matches
Mail list logo
