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
Received on Thu Jul 3 16:11:19 2003