我最近从 Subclipse 切换到了 Subversive，但遇到了一些障碍。具体来说，Subversive 似乎有一个不太灵活的身份验证机制。 Subclipse 会存储我的凭据，如果我输入错误，或者如果它们在服务器上被更改，它会重新提示我登录。 Subversive 似乎没有这样做，而是继续使用我旧的无效登录，并简单地显示一个带有 SVN 错误的弹出窗口：
Some of selected resources were not committed.
svn: Commit failed (details follow):
svn: Negotiate authentication failed: 'No valid credentials provided'
很遗憾，Google 在寻找解决此错误的方法方面没有提供太多帮助。如何清除旧的 SVN 登录并使用 Subversive 重新输入？
【问题讨论】：
标签： svn subversive
几乎所有 Subversion 客户端都试图遵守本地命令行客户端设置的标准。此客户端将身份验证信息存储在
%APPDATA%/Subversion/auth/ // on Windows
~/.subversion/auth // on Unix&Co
有关Client Credentials 的更多详细信息，请参阅 Subversion 手册。
尽管大多数 subversion 客户端都尝试使用现有数据，但它们有不同的代码库来解释这些数据。这意味着，超新版本的命令行客户端可能会使用您的 Subversive 版本不支持的身份验证方法。信息在这些文件中的存储方式也是如此。
好的一面：通常客户端不会在不需要的情况下覆盖现有文件，它们可以读取旧客户端写入的文件。
因此一个可能的解决方案是让最老的客户端写入此信息，新的客户端将读取它而不修改它。
这帮助我把命令行客户端、ant任务使用的客户端和Eclipse客户端“放在一起”了。
但这对你的情况是否有帮助是另一回事。对于第一次检查，您可以备份并删除提到的目录并试一试。
【讨论】：
我是从 Subclipse 的角度回答这个问题，但我认为这会有所帮助。
上次我查看 Subversive 时，它在其存储库对话框中收集了您的凭据，并在 Eclipse 中维护了自己的缓存。所以你必须回到那个位置来编辑它们。也可能在某个地方的 Eclipse 首选项中可用。
Subclipse 曾经以这种方式工作，但用户总是遇到这样的问题。所以早在多年前 Subclipse 1.0 发布之前，我们就彻底改变了这一点。 Subclipse 根本不收集或存储凭据，它完全遵循 Subversion，由 Subversion 来存储凭据。这种方法的好处是 Subversion 具有检测服务器密码更改等信息的智能，它应该提示您输入它们存储的新凭据。 API 的工作方式，如果您将自己的凭据存储为 Subversive，那么您将不会获得相同的机会。你只会从 Subversion 收到一个错误，就像上面的错误一样。
我并没有真正使用 Subversive，但也许它让您根本不需要在其对话框中输入凭据，在这种情况下它可以遵循 Subversion 及其缓存。
我当然会建议您切换回 Subclipse，因为它维护得更加积极，并且与 Subversion 紧密结合。 Subclipse 已经以支持 SVN 1.7 为例，并参与了新功能的开发。
【讨论】：