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.
* 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
> 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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 15 19:00:36 2006