On Jul 9, 2006, at 12:35, Alan McDonald wrote:
> If I try to do an update on my repo I get the following message
> from both
> tortoise and SVN
> Error: Working copy 'E:\Repos\gcave' locked
> Error: Please execute the "Cleanup" command.
>
> Running Tortoise Release Lock does something but does not return any
> message.
The "Release Lock" command has nothing to do with a locked working
copy. The naming similary is unfortunate.
When your working copy is locked, it means that either you are trying
to use one Subversion command while another is still running on your
working copy, or that one Subversion command has ended prematurely
and left the working copy in an inconsistent state. The cleanup
command is to be used by you when you know that the latter has
happened (as it has for you), and not the former.
"Release Lock" releases a lock that you had specifically set on a
file in the repository. You can lock files in the repository to
prevent others from attempting to modify it while you are modifying
it. This is often used for binary files like images for which merging
would not be possible.
> So then I try to run Cleanup with Tortoise or SVN and I get the
> following
> message
>
> svn.exe cleanup
> svn: In directory 'Woolley'
> svn: Can't copy 'Woolley\.svn\tmp\text-base\Additional Scans of
> Application.tif.svn-base'
> to 'Woolley\Additional Scans of Application.tif.5.tmp'
> : The system cannot find the file specified.
Could it be that you have a case collision? That you have two files
in the same directory whose names differ only in case? Like
"Additional Scans of Application.tif" and "Additional Scans of
Application.TIF"? (Check with "svn ls" on the directory's URL.) If
so, Windows' case-insensitive file system cannot handle that. If this
is the situation you have, then you may want to examile both files
(you can use "svn cat" to output them to different filenames on your
computer, outside of your working copy). Decide which one you want to
keep, then delete the one you don't need anymore directly in the
repository, passing "svn rm" the complete repository URL to the file.
Then you may need to remove the problematic file from the local
working copy (not "svn rm" -- just with Windows Explorer or
whatever). Then you should be able to update the working copy.
To prevent this from happening in the future, you can install a pre-
commit hook, as mentioned here:
http://subversion.tigris.org/faq.html
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Jul 9 16:18:34 2006