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

Re: [Issue 1385] New - "make check" tests fail if on modified ~/.subversion/config

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-07-04 01:42:59 CEST

mark benedetto king wrote:

>On Thu, Jul 03, 2003 at 07:12:45AM -0000, issues@subversion.tigris.org wrote:
>>+ As of subversion 0.24.1, depending on the entries in
>>+ "~/.subversion/config" some tests may fail.
>>+ Eg if you have a "global-ignores = never_and_nothing_to_ignore" in
>>+ your config-file basic_tests.py:20 and 21 fail with "ignored files
>>+ should not be added" and -"imported".
>>+ There may be other constellations too, so I suggest setting a new
>>+ $HOME or another ~/.subversion-path during the tests.
>>\ No newline at end of file
>Since I'm supposed to be working on merging in the --ignore patch, and
>this is sort-of related, I'm bringing this to the dev list for discussion.
>This particular problem could be solved by changing $HOME for the tests,
>or adding a --config-dir option, etc.
Oh no, don't lets even think about changing $HOME. Why? Because it won't
do a bit of good on Windows. :-)

I'd suggest two new options:

    * --no-config: Don't use any configuration data at all. This
      includes not caching auth data.
    * --config=DIR: Use configuration data from DIR.

Both options woudl be very useful for the regression tests; the first
would probably be the default for most tests, so that we'd just use
built-in default values. The second could be used for testing all sorts
of edge cases that we can't even begin writing tests for yet.

I realise that an elegant implementation is not exactly a bite-sized
task, but I think we need this functionality for 1.0.


>I believe that virtually every configurable option probably deserves
>some command-line tweakability. The fact that it is configurable means
>that not everyone wants the same thing; this is likely to also mean
>that one person might not want the same thing all of the time.
Yikes. I'd only support this if the config option parsing could be
hoisted off of the svn_config interface itself. Actually defining
explicit command line options for each and every option is a huge can of

>I also believe that we are likely to see continued "feature-creep" in the
>configurability of the application. I know that many people feel that
>"knobs are evil", but my experience is that knobs insist on existing, and
>that hiding them under the seat just makes them hard to reach.
>If there are to be more and more knobs it probably behooves us to
>formally define the relationship between the configuration file and
>the command line.

>This will enable us to manage that complexity.
>The table driven option processing is a good start. I believe that
>we just need to map those options into the "config file namespace".
>Some of this was touched on when the client-context was created.
>I also believe that a generic config-namespace-access option should
>be created (like OpenSSH's "-o").
You'd probably want to have a single option, yes; something like




except that this would complicate our option parsing logic quite a bit.
Well, needs must...
Oh, this doesn't mean we should remove shortcut options such as
--no-ignores and friends.

>Finally, I believe that we should *remove* parameters from svn_client_*
>where they overlap with this configurable behaviour. Logic should be
>based solely on the information in the client-context.
Hmmm. Yes, I agree in general, although I'd guess we don't want to be
_too_ consistent here; some commonly-used options could still remain

>This will prevent svn_client_* API changes in the face of feature-creep.
>I believe that it makes sense to do this before 1.0, in that it is
>such a large interface change.
I agree.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 4 01:43:44 2003

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.