Re: RFC: svn aliases proposal

[Kevin Pilch-Bisson <ke...@pilch-bisson.net>]

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 <ma...@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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Re: RFC: svn aliases proposal

[Philip Martin <ph...@codematters.co.uk>]

David Mankin <ma...@ants.com> writes:

> > Just as an add in to this, we should also think about per wc options.
> 
> I agree! But I don't have an easy way to solve that problem.  (I've
> been pondering it for the last several hours -- don't tell my boss.)
> 
> Possible solutions include:
> * A file in ~/.subversion/ that defines working copies & their
> * settings.  (I don't like this because if you move a WC on disk then
> * its settings change.  Unless each WC has a unique ID that is
> * associated with it and that points to something in ~/.subversion.

Have the setting be "per repository URL" rather than "per WC path".

-- 
Philip Martin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: svn aliases proposal

[David Mankin <ma...@ants.com>]

On Monday, November 25, 2002, at 04:41  AM, Kevin Pilch-Bisson wrote:

> 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.

I agree! But I don't have an easy way to solve that problem.  (I've 
been pondering it for the last several hours -- don't tell my boss.)

Possible solutions include:
* A file in ~/.subversion/ that defines working copies & their 
settings.  (I don't like this because if you move a WC on disk then its 
settings change.  Unless each WC has a unique ID that is associated 
with it and that points to something in ~/.subversion.

* Config file in .svn at the top level of the wc.  But then clients 
have to search for it.

* Config file in every wc directory's .svn.  But then the config data 
is repeated everywhere and becomes difficult to change.

A final problem is what happens when you do svn diff URL ?  How does it 
know which diff parameters to use for that repository?

I'm wide open to other suggestions.

-David

> On Mon, Nov 25, 2002 at 01:28:38PM -0600, Ben Collins-Sussman wrote:
>> David Mankin <ma...@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.
>>
>> 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."


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org