[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] default to --no-auth-cache

From: <rbb_at_rkbloom.net>
Date: 2003-01-13 22:48:30 CET

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

> > > 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

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.


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

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.