On Thu, Dec 23, 2010 at 10:09:23AM -0600, Les Mikesell wrote:
> On 12/23/2010 9:56 AM, Stefan Sperling wrote:
> >
> >
> >Yes, every svn subcommand creates it, and it has been pointed out before
> >that this might not be necessary.
> >However, I'm wondering if it's even possible to come up with a good
> > split between subcommands that should create it and ones that shouldn't.
>
> If you don't need to write/modify something there, why should it be
> created if it doesn't already exist? Can't you defer the decision
> to create until you need a write?
That would mean going into the code of each operation within
libsvn_client and sprinkle calls to the config creation code
depending on what the operation is going to do.
I don't think that's worth the bother. There are enough special cases as is.
And most people need the config or they don't care if it gets created.
So I think having a simple option to turn config creation on startup off
is a better solution. However, the implementation of this option would
probably still have to intialize config related data structures to default
values if the config isn't created, as code down the road might depend
on this.
For reference, here is the call that creates the configuration files,
from subversion/svn/main.c, with an informative comment that shows
that this has been an open question for some time:
/* ### This really belongs in libsvn_client. The trouble is,
there's no one place there to run it from, no
svn_client_init(). We'd have to add it to all the public
functions that a client might call. It's unmaintainable to do
initialization from within libsvn_client itself, but it seems
burdensome to demand that all clients call svn_client_init()
before calling any other libsvn_client function... On the other
hand, the alternative is effectively to demand that they call
svn_config_ensure() instead, so maybe we should have a generic
init function anyway. Thoughts? */
err = svn_config_ensure(opt_state.config_dir, pool);
if (err)
return svn_cmdline_handle_exit_error(err, pool, "svn: ");
Received on 2010-12-23 17:25:08 CET