Greg Stein wrote:
>On Sat, Feb 22, 2003 at 04:48:25AM +0100, Branko Cibej wrote:
>
>
>>...
>>The log message (if I were to commit this patch) would look a bit like
>>this (see, Karl, I /told/ you :svn_config_create should be publc :-) :
>>
>>
>
>Blah. Just use a hash table of options. svn_config should be about reading
>config files, not a replacment for simple name/value option pairs.
>
>"Hey! I've got this hammer here, and *that* looks like a nail! WHAM! WHAM!"
>
>:-)
>
>Seriously... just use a hash. Forget the svn_config_create stuff.
>
The point of using an svn_config_t is that you can put
FS-backend-specific options in fs-backend-specific sections, without
having to know in advance which backend you're using. Yes, I know we
have only the BDB backend at the moment. I'm sure gat appreciates every
BDB-specific top-level interface we add. :-)
>Hmm. It seems like there are two pieces here. One piece that passes config
>to affect the creation, and one piece to pass params during normal
>operation. But I didn't see any of the latter, so maybe the patch can be
>trimmed back to just the creation params [for now] ?
>
>We can always come back at some future point to add runtime params.
>
>
Well, svn_fs_new has to take the config parameter because that's where
you create the svn_fs_t, not in svn_fs_create_berkeley. I guess the
changes to the repos interface could be limited to just svn_repos_create
for now, with svn_repos_open always sending a NULL config to svn_fs_new.
That should work, yes.
--
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 Sat Feb 22 05:42:07 2003