On 13 Jan 2003, Philip Martin wrote:
> <rbb@rkbloom.net> writes:
>
> > > 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.
Yeah, cmpilato pointed me to that just after I posted. I'll post a real
log message late tonight. It'll be sometime after 10 o'clock PST before I
get to it. (Unless I get home before my wife, which will give me some
time).
> > > 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.
Okay, I kind of see that, but I don't know of anybody who would consider
storing the username in the repo a real problem. In fact, I don't know
any SCM packages that don't do it.
>
> > IMHO, the store-password
> > setting should just be toggling whether the client defaults the
> > --auth-cache option.
>
> I don't understand what you mean.
Basically, username is always stored in the wc.
If store-password == "no", then the svn client defaults to not having
--auth-cache.
If store-password == "yes", then the svn client defaults to --auth-cache
If --auth-cache is passed on the command line, then the setting of
store-password is ignored.
So, the Use Cases:
store-password = yes
svn co https://foo.com/trunk foobar
-----------------------------------
username is stored in wc
password is stored in wcA
store-password = yes
svn co https://foo.com/trunk foobar --auth-cache
-----------------------------------
username is stored in wc
password is stored in wcA
store-password = no (This ends up being the default mode)
svn co https://foo.com/trunk foobar
-----------------------------------
username is stored in wc
password is not stored in wcA
store-password = no
svn co https://foo.com/trunk foobar --auth-cache
-----------------------------------
username is stored in wc
password is stored in wc
Does that make sense now? BTW, if we were to go this way, I would change
store-password to something else, probably enable-auth-cache.
Ryan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jan 13 22:35:40 2003