Hey,
Another fine blithering from gat:-)
>Where do you read the config file(s) from, if there's no FS or
>repository yet?
>
>
If this starts to run on and on I apologize in advance.
Where to start......
* I think we all can agree that the various FS back ends will have
different config options.
* My abstractions aim to make it possible to add FS back ends without
*any* mods to the callings layers. None, goose egg, nadda. I know we
can do this. I also know that my first patch will not get us all the
way there :-)
* I concluded that we needed to allow config files to be passed through
the repos and fs layers all the way to an FS implementation hook Any
code along the way has an opportunity to sniff at any config option it
is aware of. Remember svn_config_t gives us some simple name space
capability.
* The first patch only adds the basic glue and hooks (I yanked some
other stuff). The idea is to provide sample config files (with
comments) for all the alternate back end brewings. Hey it's how I got
started on Apache :-) However, this file is provided by name to the
"svnadmin create" command line. The file is read in with the config lib
and passed as part of the create call. It will be the responsibility of
the FS layer to store that config information and to use it as necessary
for subsequent open calls. I had a solution as part of an original
version of my patch. It never saw the light of day. It was too SQL
oriented so instead I want to build a more generalized form.
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgId=207304 is
a blithering that discusses (very poorly) where I'm headed. Don't freak
out, most implementations won't need the level of capability I'm talking
about. But it will be available to those FS implementations that do
need it. And with minimal impact to those who don't.
* I believe the storing of config information needs to be handled by the
FS layer via a module I'm calling the fs_loader. For now and the near
future we can simply add the svn_config_t item to the create call and
not worry about any possible editing function calls (if ever).
* One reason I want this, for the SQL implementation, is that I want to
be able to bootstrap a fresh server from an existing SQL DB repos
(svnadmin bootstrap <mini_config>). I have other evil plans as well.
I plan to mirror the configs in the DB. Another reason is that I want
to avoid having DDL shell scripts to setup SQL repos (schema user
creates and some grants will have to be handled manually). I already
have code to build repos from config files. The config files look a lot
like a DDL script but can be passed through any supported API adapter
see: http://www.cdrguys.com/subversion/sql_fs_docs/svn_fs_sql.htm.
Errors can be handled or ignored selectively. All I need is the ability
to have my own little wad of config files. *Also* the intent is to be
able to install config files from a central config file. REMEMBER This
is all optional "ALL OF IT". From a code exposure perspective it is as
simple as reading a config and passing it along to the create call.
REALLY. End users will not have to edit more than a line or two. For
BDB, I see it defaulting to what we have today.
* These were listed at the bottom of my fs-refactor web page.
1. Move tree.c, dag.c and their partners to a baseline_impl
directory. Look for and move util candidates.
2. Commit some existing config.c extensions.
3. Commit a reworked svn_sql_config container class that is more generic.
4. Build and commit a fs_loader module which utilizes the config
container class.
5. Continue SQL work “On a branch hopefullyJ”.
* Before you guys go thinking this is some huge config change it really
isn't. In fact, it's really quite simple. The first config storage
code could simply re-materialize the config file into the repos config
directory. However, by forcing the configuration through the create call
I get the opportunity to later alter it for my own evil purposes. Pay
no attention to the man behind the curtain. REALLY:-)
>
>Well, if you had your patch on a branch, I could've looked there. .-)
>I tried to come up with an interface that's independent of the FS
>back-end. I think I succeeded in that. Once your FS abstraction layer is
>in, we can think about a better solution.
>
>
Well I think we would have been fine had I not dropped from sight for
over a month. Ugggh!!!!
But as long as you guys are open to another solution, I'm happy to undo
and redo what you have done.
I'm trying to focus on getting my master patch back up-to-date so I
don't loose any of the smaller pieces in the mix.
Once I do that, and submit an incremental or two, I will update my
design docs to be useful :-)
Later,
gat
I have to bail for the night. My wife is beginning to wonder if she
will ever see me again.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 27 02:32:37 2003