Start by separating the problem into one of four areas:
That prevents a UI symptom from being mistaken for repository corruption.
An interrupted update, commit, merge, or similar operation can leave internal working-copy administrative locks.
Use Cleanup at an appropriate working-copy root.
This is different from a repository lock held by another user.
A structural operation collided with another structural/local change.
Do not simply mark it resolved. Decide what the final file/folder location and content should be, repair the tree, then mark it resolved.
Resolve the actual content/property difference first. Then mark the item resolved.
The repository contains a newer relevant change.
Update, resolve any resulting conflicts, review/test, then commit again.
Verify that you selected a path inside the actual checkout and that its working-copy administrative data has not been deleted or replaced.
Copying only project files to a new directory does not create a Subversion working copy.
If the same repository was moved to a new server or base URL, do not use Switch merely because the URL changed. Switch is normally for changing the working-copy path to another branch/location within the same repository history.
A repository relocation operation is appropriate when the repository identity/history is the same and only its root URL changed. Verify the old and new repository URLs carefully before changing working-copy metadata.
If repository identity changed as well, a fresh checkout may be safer than pretending the new repository is the old one.
Check:
Check the repository URL, username, cached credentials, server access, and proxy/TLS configuration.
If only an external fails, remember it may contact a different server.
Verify hostname, expiration, issuing CA, and whether a corporate proxy is intercepting TLS. Do not permanently accept an unexpected identity merely to make the warning disappear.
An unversioned local file/folder may occupy a location where Update/Checkout needs to create a versioned item.
Preserve anything important, identify why the obstruction exists, then move/remove it as appropriate.
Inspect the svn:externals definition and test each external URL. Check credentials and whether the destination already exists.
See Externals.
If Visual Studio does not show the status you expect:
If command-line or another SVN client also reports unexpected status, investigate the working copy rather than treating it as only a Visual Studio display problem.
Check whether it is:
Try the appropriate whitespace/EOL options, verify the revision range, and consider retrieving merged revisions.
See Annotate / Blame.
Inspect source/target URLs and svn:mergeinfo. Do not edit mergeinfo solely to force the desired eligibility result.
A fresh checkout can be a useful comparison, but do not destroy the original working copy until all uncommitted local changes have been identified and preserved.
Include:
Check AnkhSVN GitHub issues for known problems.