Just as an add in to this, we should also think about per wc options.
For example, some projects might want you to send patches with svn diff -x
"uBbw" or something like that.
It would be good to also be able to specify options per working copy.
On Mon, Nov 25, 2002 at 01:28:38PM -0600, Ben Collins-Sussman wrote:
> 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
>
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kevin Pilch-Bisson http://www.pilch-bisson.net
"Historically speaking, the presences of wheels in Unix
has never precluded their reinvention." - Larry Wall
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- application/pgp-signature attachment: stored
Received on Mon Nov 25 20:43:05 2002