David Mankin <mankin@ants.com> writes:
> 2) Add a [aliases] section to the config file. Here is what I have
> in my config file now, as an example and starting point for discussion.
David, this proposal seems eminently reasonable to me. I think this
would be a great runtime feature.
However, your proposal has reminded me of a problem that I've been
meaning to bring up for a long time: I'm worried that we're being too
sloppy about which ~/.subversion/ runtime features are generic and
which ones are client-specific. By "generic", I mean, "a
user-controlled runtime behavior that affects the subversion
libraries". By "client-specific", I mean, "a user-controlled runtime
behavior that affects a particular client."
For example, the proxy config stuff is generic. It affects
libsvn_ra_dav, no matter which client is accessing it. So is the
'compression' option, because it how libsvn_ra_dav calls neon, and (at
the moment) the 'diff3_cmd' option, since it affects libsvn_wc and
libsvn_subr, and the 'store_password' option, which affects libsvn_wc.
In the client-specific category, you might find a runtime option about
how rapidsvn or gsvn should display information, or, by David's
proposal, options that create aliases which only the commandline
client understands. (In the "vague" category, we have
$EDITOR... should it affect libsvn_wc generally? At the moment, it
only affects the commandline client. Or should clients be able to
override the value? Maybe our nascent svn_context_t object would load
the generic runtime options and then allow clients to override them.)
Anyway, I'd like to see a clean design step forward. I'd like it to
be perfectly clear, by looking in ~/.subversion, exactly which runtime
options affect svn libraries, and which ones affect particular
clients.
Here's my super-simple idea: create a ~/.subversion/clients/
subdirectory, and tell clients they're free to use the area if they
wish. As long as a client creates a private subdir in there, it can
stash private runtime data. If clients take advantage of it, then
great... users can move their ~/.subversion directory from one machine
to another and not have to hunt down ~/.gsvn, ~/.rapidsvn, etc.
Either way, it's no extra work for the svn libraries. If people like
this idea, then the real task here is to separate commandline-client
runtime options and put them deeper down. The top-level
~/.subversion/config file should only contain generic options.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 25 20:30:40 2002