How can I make subversion reset the stored passwords/users and remember my authentication credentials?

Background: I used to have everything working just fine on my fresh install:

$ svn co https://domain:443/ test1
Error validating server certificate for 'https://domain:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: **REMOVED**
 - Valid: **REMOVED**
 - Issuer: **REMOVED**
 - Fingerprint: **checked with issuer and REMOVED**
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://domain:443> Subversion repository
Password for 'nicdumz-machine-hostname':
Authentication realm: <https://domain:443> Subversion repository
Username: nicdumz
Password for 'nicdumz':

# proceeds to checkout correctly

$ svn co https://domain:443/ test2

# checkouts nicely, without asking for my password.

At some point I needed to commit stuff using a different account. So I did that

$ svn ci --username other.user
Authentication realm: <https://domain:443> Subversion repository
Password for 'other.user':

# works fine

But since then, everytime I want to commit as 'nicdumz' (default user, all repos have been checked-out with that user), it prompts me for my password:

$ svn ci
Authentication realm: <https://domain:443> Subversion repository
Password for 'nicdumz':

Hey come on, why :) The same happens if I want a fresh checkout, since read-access is also protected.

So I tried fixing the issue by myself. I read around that ~/.subversion/auth was storing credentials, so I removed it from the way:

$ cd ~/.subversion
$ mv auth oldauth
$ mkdir auth

It seemed to work at first, because svn had forgotten about certificate validation:

$ svn co https://domain:443/ test3
Error validating server certificate for 'https://domain:443':
 - The certificate is not issued by a trusted authority. Use the
   fingerprint to validate the certificate manually!
Certificate information:
 - Hostname: **REMOVED**
 - Valid: **REMOVED**
 - Issuer: **REMOVED**
 - Fingerprint: **checked with issuer and REMOVED**
(R)eject, accept (t)emporarily or accept (p)ermanently? p
Authentication realm: <https://domain:443> Subversion repository
Password for 'nicdumz-machine-hostname':
Authentication realm: <https://domain:443> Subversion repository
Username: nicdumz
Password for 'nicdumz':

# proceeds to checkout correctly

$ svn up
Authentication realm: <https://domain:443> Subversion repository
Password for 'nicdumz':

What? how is this happening?

If you have suggestions to investigate more about the behaviour, I am very interested. If I'm correct, there is no way to do a verbose svn up or anything of the like, so I'm not sure should I go for investigation. Oh, and for what it's worth:

$ svn --version
svn, version 1.6.6 (r40053)
   compiled Oct 26 2009, 06:19:08

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository access (RA) modules are available:

* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
  - handles 'http' scheme
  - handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
  - with Cyrus SASL authentication
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

Well, I had the same problem, and I deleted the auth directory. I then did:

svn --username xxx update

which asked me for my password, but then that was it. All I can say is, deleting the auth directory worked for me. Do you have the proper options in your servers file? Namely (I think):

store-passwords = yes
store-plaintext-passwords = yes

in the [global] section. I'm not 100% sure, but it may help.