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.
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 stop. It goes on with merging and adding new files. But it is not able to write this to the locked working copy anymore.
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 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?
-----Original Message-----
From: Stefan Küng [mailto:tortoisesvn@gmail.com]
Sent: woensdag 15 november 2006 19:00
To: dev@tortoisesvn.tigris.org
Subject: Re: BUG in update
Wim Bonjean wrote:
> Thank you for taking your time to have a look at this bug. I am not sure
> if it is a bug in TSVN or in SVN, I report it here first.
>
> Hat follows is a description of what happens, for the sake of simplicity
> I have removed a part of the paths in the file paths:
>
> A file that has the needs-lock property (pageframe.fla), is opened in an
> application. This application locks the file so that, when we do an
> update, svn can not update the file as it is locked by the application.
>
> So we do an update and get these responses from TSVN:
>
>
> Updated "flash\pageframe.fla" (this is the file locked by the application)
> Added "flash\test.txt"
> Error In directory "flash"
> Error Can't move "flash\_svn\tmp\pageframe.fla.tmp" to
> "flash\pageframe.fla" : Access is denied.
>
> This is all normal behavior is what I thought. But something has gone
> wrong. Should the update have stopped when it noticed that the file was
> locked by an application? The test.txt file was added to the directory.
>
> Now when we close the file (pageframe.fla) in the application and update
> again we get this response:
>
> Error Working copy "flash" locked
> Error Please execute the Cleanup command
>
> Why is it locked? This is not normal right? So I do the cleanup command
> and that finishes without an error.
You have to know that there are multiple meanings of the word 'locked':
* locked in the sense that you made the file readonly, and to prevent
other users from committing the same file (i.e. 'svn lock')
* locked by other applications so Subversion can't access it (i.e.
access denied)
* locked working copy, which means some operation couldn't finish
correctly and the working copy is still locked, i.e. prevents other
Subversion operations from running (a working copy has to be locked so
other applications can't interfere with e.g. an update).
So what you've seen here is a working copy lock, since the update didn't
succeed.
> Then I update again to get the latest update for the pageframe.fla file
> and I get this response:
>
> Error: Failed to add file: "flash\test.txt": object of the same name
> already exists
>
> Off course it exists, it was added the first time I did the update when
> the other file was locked.
It was added, but Subversion couldn't update the working copy
information. So the file is still unversioned. And Subversion never
overwrites unversioned files during an update. You have to first remove
that file, then the update will work.
> So when I delete that test.txt file I can update and the file gets added
> again and I get an updated version of the pageframe.fla file.
>
> This is a bug that slipped in since we updated to version 1.4 I think.
No, this has always been that way. Ever since the first version.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Nov 15 19:30:54 2006