升级MS OneDrive后本地SVN工作副本无法识别的解决方案咨询

别慌，这种情况我碰到过好几次，OneDrive升级时的文件同步或权限调整很容易搞乱SVN的本地元数据。下面是几个能让SVN重新识别工作副本的方法，按从简单到复杂的顺序来试：

方法一：检查并修复.svn文件夹权限 #

OneDrive升级后经常会修改本地文件的权限，导致SVN无法读取隐藏的.svn文件夹（这是每个工作副本目录里存储本地元数据的核心文件夹）：

• 打开你的SVN工作副本根目录，在文件资源管理器的「查看」标签里勾选「隐藏的项目」，显示出.svn文件夹
• 右键点击根目录下的.svn文件夹，选择「属性」→「安全」标签
• 确认当前登录用户拥有「读取 & 执行」「列出文件夹内容」「读取」这三项权限；如果没有，点击「编辑」添加当前用户并赋予这些权限，最后点击「应用」「确定」
• 重启TortoiseSVN/AnkhSVN，看看能不能正常识别工作副本

方法二：用SVN命令行重新关联仓库 #

如果权限没问题，可能是本地元数据和服务器仓库的关联被破坏了，用命令行强制重新关联就行：

1. 打开CMD或PowerShell，导航到你的工作副本根目录（比如输入cd D:\MySVNWorkspace\MyProject）
2. 执行命令：svn switch --relocate <原仓库URL> <当前仓库URL>
   • 要是仓库URL没变化，两个参数填一样的就行；如果换过地址，就填旧的和新的仓库地址
3. 执行完后输入svn status，如果能正常显示本地修改，说明关联成功了，TortoiseSVN/AnkhSVN也会跟着恢复识别

方法三：替换损坏的.svn元数据 #

如果上面两种方法都没用，大概率是.svn文件夹里的文件被OneDrive同步损坏了。操作前一定要先备份整个工作副本，避免丢失本地修改：

1. 从SVN服务器上检出一个全新的临时副本到其他目录
2. 把临时副本根目录下的.svn文件夹复制到你的现有工作副本根目录，覆盖原来的.svn文件夹
3. 右键现有工作副本，选择TortoiseSVN的「SVN Update」，注意不要勾选「覆盖本地修改」，让SVN重新同步元数据和本地文件的差异
4. 完成后检查本地修改是否保留，以及SVN是否正常识别

方法四：针对部分失效目录的修复 #

如果只有个别子目录不被识别，不用动整个根目录：

• 找到失效的子目录，显示隐藏文件后删除该目录下的.svn文件夹
• 右键该目录，选择TortoiseSVN的「Update to Revision」，选择HEAD版本，勾选「恢复外部项目」，点击确定
• SVN会重新生成该目录的.svn元数据，同时保留你的本地修改（只要没和服务器版本冲突）

内容的提问来源于stack exchange，提问作者Brie