- Subclipse vs Subversive - a discussion on Eclipse plugins
- Slow Subversion Performance over HTTPS
- Synchronising SVN and Git
Error: XYZ has no ancestry information.
This was using the Eclipse SVN client. I tried and tried and couldn’t get around this error. Eventually I gave up and just moved my workspace to a new location, and checked out all my projects again.
There doesn’t seem to be ANY help on the SVN mailing list about this. :(
Error: commit item XYZ has copy flag but an invalid revision
I think I managed to achieve this after moving a folder in Eclipse (which resulted in a svn add and svn delete), renaming the folder back to the deleted folder manually in Explorer, and trying to commit. No series of updates or cleanups would resolve this.
The solution is to delete not only the containing folder of the folder, but the containing folder of that folder as well. You can then update and re-merge your changes as necessary.
Error: REPORT of XXX Could not read chunk size: Secure connection truncated
Note that this means that per-path authentication will essentially be ignored.
One possible symptom of this problem is that you can
svn update individual directories fine, but trying to
svn update a huge directory fails. Another solution may be to refactor your repository into smaller chunks, to prevent this memory/time/stability leak.
You might have a file listed locally as added, but remotely not within the repository. Check your Apache
error.log for messages like these:
[error] [client 10.1.1.31] Provider encountered an error while streaming a REPORT response. [404, #0] [error] [client 10.1.1.31] A failure occurred while driving the update report editor [404, #160013] [error] [client 10.1.1.31] Working copy path XXX does not exist in repository [404, #160013]
The only solution I could think of was checking out the entire local folder again, and then manually merging any missing files through a virtual export of the problematic folder.
Error: Error parsing svn:externals property on XXX
This can occur if you are trying to set a
svn:externals property without a target like so:
svn:externals operates on a particular directory, so the property should be:
Read-only Database Errors
If you get one of the following errors when trying to commit a change:
- Can’t set file XXX read-write: The system cannot find the file specified.
- Attempt to write a readonly database
Then your repository database may be read-only. This can be resolved by applying a
chmod g+w REPO/db/rep-cache.db to the repository database. (more)
Error: Error reading spooled REPORT request response: digest mutual authentication failure: client nonce mismatch
I was getting this wildly unhelpful error only in certain circumstances: SVN was working fine to update, commit and checkout, but it was failing when trying to merge branches. In particular, my SVN was setup to host via Apache using
mod_dav_svn and using Digest authentication rather than SSL.
One step to try and work out these problems is by only issuing one command at a time:
>svn ls http://host/svn/project/trunk.file trunk.file >svn ls http://host/svn/project/trunk.file svn: E175002: GET of '/svn/project/! svn/bc/59/trunk/file': Digest mutual authentication failure: client nonce mismatch (http://host)
Another thing you can try to do is to set
neon-debug-mask in your client
servers configuration file, to get much more detailed information on the authentication process (refer here to understand the value of this field):
neon-debug-mask = 138
You might also have a problem with
svn-auth.htdigest file having correct group permissions, but not correct user permissions.
$ sudo chown www-data svn-auth.htdigest
I don’t know what the actual cause of the problem was, but as I was behind a web proxy, using a different proxy (or removing the proxy entirely) solved the problem.
- svn diff ‘path not found’ and ‘Error reading spooled REPORT request response’
- Can anyone help? Server was not authenticated correctly
TortoiseSVN 1.7 does not display modified svn:externals in commit dialog
I think this has to do with the recent change to a new working copy format in 1.7.x. The solution seems to involve executing a fresh checkout.