> > You didn't provide a log message :-(
> Sorry, most of the projects I have been involved with don't ask for one.
> Here it is:
> Change the default behavior of the client to not cache authentication
> information. This can be enabled by passing --auth-cache
Please read the HACKING file for a description of log messages.
> > Here's how the current code works: whether auth data is stored is
> > controlled by the --no-auth-cache command line option. The
> > store-password setting is only relevant if auth data is being stored.
> > If auth data is being stored then the username is always stored, but
> > the password is only stored if store-password allows.
> > So did you mean to change the store-password behaviour?
> Okay, I read the docs incorrectly. No, this shouldn't be changed. Of
> course, I find this rather confusing. Basically, you are saying that it
> is possible to pass --auth-cache on the command line, and still not have
> their password cached, based on what store-password is set to. Why are
> there two different options for how this works?
The two options control different things, they have different effects.
Setting store-password to no allows the username to be cached without
the password. Then subsequent commands will prompt for the password
and use the stored username. This is particularly useful if the
repository username is different from the system username, assuming
one considers the repository username to be sufficiently non-sensitive
to allow it to be cached. Without it Subversion makes a first guess
at the repository username using the system username, prompts for a
password, fails authentication, prompts for a username and prompts for
a password a second time.
> IMHO, the store-password
> setting should just be toggling whether the client defaults the
> --auth-cache option.
I don't understand what you mean.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Mon Jan 13 22:22:53 2003