On Tue, Apr 22, 2008 at 10:10:45AM -0400, Karl Fogel wrote:
> Stefan Sperling <stsp_at_elego.de> writes:
> > Does anyone oppose moving the whole [auth] section from 'config' to
> > 'servers' for consistency?
>
> As long as we maintain compatibility...
I will deprecate the old location in the comments, like this:
"[auth]" NL
"### Set store-passwords to 'no' to avoid storing passwords in the" NL
"### auth/ area of your config directory. It defaults to 'yes'," NL
"### but Subversion will never save your password to disk in" NL
"### plaintext unless you tell it to (see below)." NL
"### Note that this option only prevents saving of *new* passwords;" NL
"### it doesn't invalidate existing passwords. (To do that, remove" NL
"### the cache files by hand as described in the Subversion book.)" NL
+ "### NOTE: This option can now be specified in the 'servers' file" NL
+ "### in your config directory. This location for this option has" NL
+ "### been deprecated. Anything specified here is overridden by" NL
+ "### settings specified in the 'servers' file." NL
"# store-passwords = no" NL
> But why is there a connection between which file the "[auth]" section
> lives in (a user-visible question) and which URLs we use that data for
> (an internal code-flow issue)?
Because 'config' is read before the subcommand is run, which
then figures out whether to contact a server, and which one.
While reading 'servers', we need to know which server we're contacting,
because we may need to match a server group:
[groups]
server1 = *.tigris.org
[server1]
store-plaintext-passwords = no
[global]
store-plaintext-passwords = yes
> The choice of which config file to use should be made based on what will
> make most sense for users, who don't know or care how our code is
> organized internally. It sounds like these two issues are maybe getting
> mixed together, in your comments above?
No, the code enforces this. But note that having all the [auth]
settings in 'servers' makes much more sense anyway, because
there, they can be configured on a per-server basis.
It also aligns much more naturally with the layering, since
authentication is done only if the RA layer is entered anyway,
which has always been getting its configuration from 'servers'.
The [auth] section in 'config' was a mistake, it would have
been much more natural to put it in 'servers' in the first place.
--
Stefan Sperling <stsp_at_elego.de> Software Monkey
German law requires the following banner :(
elego Software Solutions GmbH HRB 77719
Gustav-Meyer-Allee 25, Gebaeude 12 Tel: +49 30 23 45 86 96
13355 Berlin Fax: +49 30 23 45 86 95
http://www.elego.de CEO: Olaf Wagner
Store password unencrypted (yes/no)? No
- application/pgp-signature attachment: stored
Received on 2008-04-22 18:41:55 CEST