Subversive Reject Credentials

Question

I recently switched from Subclipse to Subversive, and I'm running into some roadbumps. Specifically, Subversive seems to have a much less flexible authentication mechanism. Subclipse would store my credentials, and if I entered them incorrectly, or if they had been changed on the server, it would re-prompt me for my login. Subversive doesn't seem to do this, and instead will continue to use my old invalid login, and simply show a popup with SVN error:

Some of selected resources were not committed.
svn: Commit failed (details follow):
svn: Negotiate authentication failed: 'No valid credentials provided'

Unfortunately, Google hasn't been much help with finding workarounds for this error. How do I clear my old SVN login and re-enter it with Subversive?

Answer 1

I am answering this from the Subclipse perspective but I think it will be helpful.

Last time I looked at Subversive it collected your credentials in its repository dialog and it maintained its own cache in Eclipse. So you have to go back to that location to edit them. Might also be available in the Eclipse preferences somewhere.

Subclipse used to work this way, but users were always getting problems like this one. So back before Subclipse 1.0 shipped many years ago we changed this completely. Subclipse does not collect or store credentials at all, it completely defers to Subversion and it is up to Subversion to store credentials. The benefit of this approach is that Subversion has the intelligence to detect something like your server password changed and it should prompt you for fresh credentials that it them stores. The way the API works, if you store your own credentials as Subversive does then you do not get the same opportunity. You will just get an error from Subversion like the one above.

I do not really use Subversive, but perhaps it lets you not enter credentials at all on its dialog in which case it can defer to Subversion and its cache.

I would of course recommend you switch back to Subclipse as it is more actively maintained and is closely aligned with Subversion. Subclipse already supports SVN 1.7 as an example and was involved in development of new features.

Answer 2

Almost all Subversion clients try to adhere to the standards set by the native command line client. This client stores the authentication infos in

%APPDATA%/Subversion/auth/    // on Windows
~/.subversion/auth            // on Unix&Co

More details on Client Credentials can be found in the Subversion book.

Although most subversion clients try to use existing data they have nevertheless different code bases interpreting this data. This means, that an ultra-new version of command line client might use authentication methods not supported by your version of Subversive. The same is true for the way in which the information is stored within these files.

On the bright side: Usually clients don't overwrite existing files without need and they can read files written by older clients.

So a possible solution is to let the oldest client write this information, the newer clients will read it without modifying it.

This helped me once to bring the command line client, the client used by the ant task and the Eclipse client "together".

But whether this helps in your situation or not is another thing. For a first check you could backup and delete the mentioned directories and give it a try.