[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: Kevin Pilch-Bisson <kevin_at_pilch-bisson.net>
Date: 2002-11-25 13:41:54 CET

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

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