You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mark benedetto king <mb...@lowlatency.com> on 2003/07/03 14:11:21 UTC
Re: [Issue 1385] New - "make check" tests fail if on modified ~/.subversion/config
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.
I feel that we have a general lack of rigor in the relationship between
the config file and the command line, and ultimately in the interface
to svn_client_*.
Take a look at the interface to svn_client_status:
svn_error_t *
svn_client_status (apr_hash_t **statushash,
svn_revnum_t *youngest,
const char *path,
svn_boolean_t descend,
svn_boolean_t get_all,
svn_boolean_t update,
svn_boolean_t no_ignore,
svn_client_ctx_t *ctx,
apr_pool_t *pool);
Because the client context contains the config, it was not necessary
to add a "const char *ignores" parameter in order to add the "global-ignores"
config support. However, now that we want to change the command-line client
to be able to override the global-ignores, we have some choices:
1.) add a parameter to svn_client_status (breaking the interface), and logic
in svn_client_status to have this value override the configured value.
2.) add the parameter to svn_client_status, and remove the logic in
svn_client_status that looks at the configurable variable.
3.) update the config structures in memory based on the command-line
There are obviously other choices specific to this example (perhaps
replacing the no_ignore boolean with a tri-state variable), but I'm
looking more at the systemic problem.
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.
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").
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.
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.
--ben
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1385] New - "make check" tests fail if on
modified ~/.subversion/config
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Fri, 2003-07-04 at 10:03, Branko Čibej wrote:
> No no no. Our config file format is compatible with Pythons ConfigParser
> class. This was done on purpose, and I wouldn't want to change that. And
> we don't need more than one level of scoping in the config files, IMHO.
Ah, that makes sense. I guess a command-line syntax to arbitarily
control the configuraton data would be all that's required then.
daniel
--
Signature at: http://www.mel.au.adaptiveinternational.com/~danpat/signature.txt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1385] New - "make check" tests fail if on modified ~/.subversion/config
Posted by Branko Čibej <br...@xbc.nu>.
Daniel Patterson wrote:
>On Fri, 2003-07-04 at 09:42, Branko Čibej wrote:
>
>
>>mark benedetto king wrote:
>>
>>
>>>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 don't know whether this discussion is heading down this path or not,
> but perhaps a config file format change might better support
> this kind of thing? Time to get out the bikeshed-painting brushes...
>
No no no. Our config file format is compatible with Pythons ConfigParser
class. This was done on purpose, and I wouldn't want to change that. And
we don't need more than one level of scoping in the config files, IMHO.
--
Brane Čibej <br...@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
Re: [Issue 1385] New - "make check" tests fail if on modified
~/.subversion/config
Posted by Daniel Patterson <da...@adaptiveinternational.com>.
On Fri, 2003-07-04 at 09:42, Branko Čibej wrote:
> mark benedetto king wrote:
> >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 don't know whether this discussion is heading down this path or not,
but perhaps a config file format change might better support
this kind of thing? Time to get out the bikeshed-painting brushes...
A good (my bikeshed) model for this that I've seen is the
configuration used by "apt" in Debian. And I quote:
Syntacticly the configuration language is modeled after what
the ISC tools such as bind and dhcp use. Each line is of the form
APT::Get::Assume-Yes "true";
The trailing semicolon is required and the quotes are optional.
A new scope can be opened with curly braces, like:
APT {
Get {
Assume-Yes "true";
Fix-Broken "true";
};
};
......
All of the APT tools take a -o option which allows an arbitary
configuration directive to be specified on the command line. The
syntax is a full option name (APT::Get::Assume-Yes for
instance) followed by an equals sign then the new value of the
option. Lists can be appended too by adding a trailing :: to the
list name.
For example, I regularly override the proxy cache control by doing:
apt-get -o acquire::http::proxy::no-cache="yes" install subversion
All the options are settable this way.
The parser for this config file is reasonably trivial (I remember
hearing in the order of 300 lines) and is extremely flexible.
daniel
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [Issue 1385] New - "make check" tests fail if on modified ~/.subversion/config
Posted by Branko Čibej <br...@xbc.nu>.
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 <br...@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