[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: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-07-03 16:11:21 CEST

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.


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

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.