Re: BUG in update

Wim Bonjean wrote:
> Thank you to for taking the time to read my Bug report.
>
> You say that I experienced a working copy lock. But I don't think
> that is the situation, because in the situation when you have a
> "locked working copy" and you update you get an error saying the
> working copy is locked.

I meant you have a working copy lock when you try the update after the
failed operation. Before, when the operation fails you have a locked
file by another application.

> In my case the update starts as if nothing is wrong. I am sure in my
> case the file is locked by another application and subversion can't
> access it.
>
> What I think that happens is this:
>
> The update encounters a locked file and as a reaction on this it
> locks the working copy. What goes wrong is that the update does not

Subversion locks the working copy *before* it starts any operation which
can modify the working copy. So before Subversion starts the update, it
locks the working copy.

> stop. It goes on with merging and adding new files. But it is not
> able to write this to the locked working copy anymore.

You say after the error message, the merge still goes on? That would be
very wrong.

> I don't say it should stop updating as this might be a stupid
> solution, a better solution could be one of these: - Wait for the

No, that wouldn't be stupid but the right way to do. And I thought that
this is what Subversion does.

> update to end and then lock the working copy because a locked file
> was encountered. - Do not lock the working copy, but just display a
> conflict warning that the locked file was not updated. - do adding of
> files before updating and merging of files.
>
> You say this is not a bug. But is this correct behavior? I find it
> very strange that TSVN goes on adding files although it knows the
> working copy is locked. Shouldn't this be handled to avoid the
> cleanup and manual deletion of the files afterwards?

How should Subversion know that it should wait for another application
to close the open file? It doesn't know that. It could also be that
you've set the access rights on that file so that Subversion can't
access it. Or some other problem which leads to access-denied errors
when Subversion tries to open that file. Waiting would be desasterous:
it could wait forever.
So, the best way is to throw an error and stop the operation. And if you
say that's not happening (that it goes on with the update), then you
have to report this on the Subversion mailing list.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org