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