When starting all over is not an option...
I deleted the log file in the .svn
directory (I also deleted the offending file in .svn/props-base
), did a cleanup, and resumed my update.
Metadata should not be managed in source control. They contain mostly data relevant to your workspace.
The only exception is the .launch
XML files (launcher definition).
They are found in
[eclipse-workspace]\.metadata\.plugins\org.eclipse.debug.core\.launches
And they should be copied into your project directory: When your project is refreshed, those configurations will be displayed in the "Run configuration" dialog.
That way, those launch parameter files can be also managed into the SCM.
(Warning: Do uncheck the option "Delete configurations when associated resource is deleted" in the Run/Launching/Launch Configuration preference panel: It is common to soft-delete a project in order to import it back again - to force a reinitialization of the eclipse metadata. But this option, if checked, will remove your detailed launch parameters!)
project-dir/.project
project-dir/.classpath
project-dir/.settings/*
should be in your SCM (especially .project
and .classpath
according to the Eclipse documentation).
The goal is that anyone can checkout/update his/her SCM workspace and import the Eclipse project into the Eclipse workspace.
For that, you want to use only relative paths in your .classpath, using linked resources.
Note: it is better if project-dir
refers to an "external" project directory, not a directory created under the eclipse workspace. That way, the two notions (eclipse workspace vs. SCM workspace) are clearly separated.
As ipsquiggle mentions in the comment, and as I have alluded to in an old answer, you can actually save the launching configuration as shared file directly in your project directory. All launching configuration can then be versioned like the other project files.
(From the blog post Tip: Creating and Sharing Launch Configurations from KD)

Best Solution
If you have deleted all
.svn
folders in your local working copy, it shouldn't be versioned anymore. Please note that older version of SVN, use to create a hidden.svn
folder in all folders, not only in the root folder or direct subfolders.You could also do an
export
command to create a full non-versioned copy in a target directory to avoid the manual delete of.svn
folders.Another issue that could cause this error is that in the new repository, you are already have files or directories with the same name as the directories/files you are trying to add. A good practice would be to import your files in an empty directory to avoid name conflicts.
So, to summarize, the procedure would be like this:
.svn
folders manually