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

Re: RFC: svn aliases proposal

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-11-25 20:28:38 CET

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

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.