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.
[snip]
>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
worms.
>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.
>
Right.
>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
--option=file,section,name:value
e.g.,
--option=servers,global,neon-debug-mask:foobar
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
parameters.
>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