A working copy of an app is returning the described error when trying to Update.
Can this error be caused by having insufficient permissions to write to the folder (or some of the files within it)?
I've tried the "Release Lock" function and Tortoise tells me there are no locks.
I got the same error when copying whole SVN repo to another location. When I checked Windows permissions, everything seemed fine. I reapplied Windows permissions and all of a sudden Windows applied permissions and from then on everything is working fine.
This error can occur if write access is not available for your group to the rep-cache.db file in your repository on the SVN server. You'll need access to the SVN server or get someone who has access.
Search for the rep-cache.db file:
Go to the db subdirectory under the repository that you are working with and type the following:
Typically the group has only read-only access when this error occurs. This will give the group read/write, which should stop the error from occurring.
I got this error recently and it was because I had logged into my development environment using the wrong user account. I had set the project up on a development VM using the local Administrator account. I got this error when I logged in user my personal account who was not a local Windows Admin. So in my case it was due to Windows permissions.
For Ubuntu users
when you setup project on a public directory such as
home
don't usesudo
on it. ex:sudo mkdir folderName
usemkdir folderName
or create it manually.when you created using
sudo
you get the folder as locked.(check image with and withoutsudo
)As well don't use
sudo svn co http://path/to/trunk/ ./
use withoutsudo
like this
svn co http://path/to/trunk/ ./
Had this on windows 7 system, after waiting 10 mins the SVN update was available without problems. Maybe a problem during Tortoise startup.
Working copies on shares frequently cause problems (including/especially with permissions) - as a result, it is not a recommended configuration. There actually was a bug in quite a few releases of Samba that was triggered by SVN 1.5 or 1.6 which caused a number of issues like this. It can be worked around with a change to the Samba configuration - but this may not resolve all of your issues. Best practice is to not do what you are doing - only operate on WCs locally, not via shares