You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2003/02/26 20:20:20 UTC
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
brane@tigris.org writes:
> Modified: trunk/subversion/svnadmin/main.c
> ==============================================================================
> --- trunk/subversion/svnadmin/main.c (original)
> +++ trunk/subversion/svnadmin/main.c Wed Feb 26 13:52:07 2003
> @@ -229,11 +235,18 @@
> struct svnadmin_opt_state *opt_state = baton;
> svn_repos_t *repos;
> apr_hash_t *config;
> -
> + apr_hash_t *fs_config = NULL;
> +
> + if (opt_state->bdb_txn_nosync)
> + {
> + fs_config = apr_hash_make (pool);
> + apr_hash_set (fs_config, "bdb-txn-nosync", 14, "1");
> + }
> +
Please, please don't hard-code this string here (and everywhere else).
Make a nice #define in svn_fs.h. Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by Branko Čibej <br...@xbc.nu>.
cmpilato@collab.net wrote:
>brane@tigris.org writes:
>
>
>
>>Modified: trunk/subversion/svnadmin/main.c
>>==============================================================================
>>--- trunk/subversion/svnadmin/main.c (original)
>>+++ trunk/subversion/svnadmin/main.c Wed Feb 26 13:52:07 2003
>>@@ -229,11 +235,18 @@
>> struct svnadmin_opt_state *opt_state = baton;
>> svn_repos_t *repos;
>> apr_hash_t *config;
>>-
>>+ apr_hash_t *fs_config = NULL;
>>+
>>+ if (opt_state->bdb_txn_nosync)
>>+ {
>>+ fs_config = apr_hash_make (pool);
>>+ apr_hash_set (fs_config, "bdb-txn-nosync", 14, "1");
>>+ }
>>+
>>
>>
>
>Please, please don't hard-code this string here (and everywhere else).
>Make a nice #define in svn_fs.h. Thanks.
>
>
Yes, yes, I will. It's on my todo list.
--
Brane Čibej <br...@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
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hold up for a moment guys.
I'm writing a detailed response about configs.
I found my previous posting. . ........ Scary!!!!
Karl, I just can't imagine how anyone could be confused by my
rambling:-) Yikes!!
I'm attempting to layout the config mods as best I can.
Thanks,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by cm...@collab.net.
=?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <br...@xbc.nu> writes:
> Glenn A. Thompson wrote:
>
> > Hey,
> > Forgive me for being blunt, but I don't like this config solution at all.
> > We are going to add a config option for every little thing for every
> > fs type? .... Bah!
>
> Perhaps, perhaps not. For "svnadmin create", we'll probably have both:
> an option for every little thing, and an option to read other options
> from a config file. There's nothing wrong with being flexible.
>
> > My solution, which I'm in the process of getting back up-to-date, is
> > more flexible.
> > I use the svn_config_t structure which is loaded by svnadmin using
> > svn_config_read.
>
> Where do you read the config file(s) from, if there's no FS or
> repository yet?
Oh, I'm sure we can dump them into the same place our new repository
templates wind up... ;-)
> Well, if you had your patch on a branch, I could've looked
> there. .-)
That's not Glenn's fault. We went over all this before, and we were
more than willing to give him a branch, but we wanted to see some
smaller patches for trunk-ready concepts first. There are a couple of
more steps to Glenn's changes that should be applied to the trunk
first, *then* a branch made for the experimental stuffs.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Server side configs
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
>The templates are a mechanism for an administrator to easily crank out
>preconstructed and preconfigured repositories.
>
>
OK this is what I thought.
> on-disk templates specify the files and dirs on disk. Yes, these could
> contain config files for <whatever>, including DB config files.
>
> in-repos templates specify what revision 1 of the repository will look
> like. That definitely cannot specify a config, since it exists at an
> entirely different semantic level.
> (not yet implemented)
>
>
Hmmm. This is interesting. It brings to mind one of a couple things I
remember putting on my "needs to be worked out" list.
I'm still re-engaging my brain on all this FS stuff, as you know it's
not for the faint of heart:-) Buuuut.
I remember wanting to ask about the possibility of making the repos
create more atomic. Not for the usual protection reasons. As I recall
there are two separate steps which result in the creation of a repos
which is "ready for action". Step one was setting up the tables and
step two was inserting the initial data.
I have a mechanism to do this as a single step completely from config
files. It allows me to create different schemas different ways for
different DBs. I remember having a little difficulty "priming the pump"
(using the two step approach) with either Oracle or MySQL can't recall.
I'll re-find my problem soon enough I guess:-)
Anyway if memory serves it was related to revision 0. Is what you
mention above related to this or is it for something else, and if so,
what?
>For BDB-based systems, the database config exists inside the db/
>subdirectory, and (for safety reasons) libsvn_fs will not construct a BDB
>environment in an already-existing directory. Thus, you cannot prepopulate
>the db/DB_CONFIG file using on-disk templates. If somebody can think of a
>way to do so, then we can do the necessary tweaks.
>
>[ one idea might be to create the db/ subdir *first*, then use the template
> to drop files into the repos, possibly overwriting db/DB_CONFIG; but that
> just seems way dangerous to me... ]
>
Me too. I'll get it worked out after I get my current patch fully in
place.
Thanks,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Server side configs
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Feb 28, 2003 at 05:18:47PM -0500, Glenn A. Thompson wrote:
>...
> My SQL support code is definitely impacted by your approach. So, I'm
> trying to get a better handle on templates. Specifically, in-repos
> templates threw me. Are they more narrow in scope than on-disk
> templates? It seems we could never have config information in an
> in-repos template that is required to successfully open a repos. But,
> on-disk templates potentially could. Were they intended only for hooks
> and other non DB specific configuration? Or was DB configuration *ever*
> supposed to be part of their charter? Are there some good thread
> discussions I can go read?
The templates are a mechanism for an administrator to easily crank out
preconstructed and preconfigured repositories.
on-disk templates specify the files and dirs on disk. Yes, these could
contain config files for <whatever>, including DB config files.
in-repos templates specify what revision 1 of the repository will look
like. That definitely cannot specify a config, since it exists at an
entirely different semantic level.
(not yet implemented)
For BDB-based systems, the database config exists inside the db/
subdirectory, and (for safety reasons) libsvn_fs will not construct a BDB
environment in an already-existing directory. Thus, you cannot prepopulate
the db/DB_CONFIG file using on-disk templates. If somebody can think of a
way to do so, then we can do the necessary tweaks.
[ one idea might be to create the db/ subdir *first*, then use the template
to drop files into the repos, possibly overwriting db/DB_CONFIG; but that
just seems way dangerous to me... ]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Server side configs
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
> Yeah, I re-looked at what you did and realized they are very compatible.
Well, compatible isn't really true:-) Since none of my existing
fsrefactor code needs the svn_config_t *yet*, I'm pulling that out of
my master patch for now. I still need something more robust long-term.
My SQL support code is definitely impacted by your approach. So, I'm
trying to get a better handle on templates. Specifically, in-repos
templates threw me. Are they more narrow in scope than on-disk
templates? It seems we could never have config information in an
in-repos template that is required to successfully open a repos. But,
on-disk templates potentially could. Were they intended only for hooks
and other non DB specific configuration? Or was DB configuration *ever*
supposed to be part of their charter? Are there some good thread
discussions I can go read?
Thanks,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Server side configs was (Re: svn commit: rev 5119 - in trunk/subversion:
svnadmin i ...... )
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
>
>
>I only had time to take a quick look at this post of yours, so I don't
>have any specific comments at this time. FWIW, your plan seems entirely
>sane to me -- it's more or less an extension and generalisation of what
>I've done already.
>
>
Yeah, I re-looked at what you did and realized they are very compatable.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by Branko Čibej <br...@xbc.nu>.
Glenn A. Thompson wrote:
> Hey,
>
> Another fine blithering from gat:-)
:-)
I only had time to take a quick look at this post of yours, so I don't
have any specific comments at this time. FWIW, your plan seems entirely
sane to me -- it's more or less an extension and generalisation of what
I've done already.
More on Sunday, when I get back.
--
Brane Čibej <br...@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
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
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
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by Branko Čibej <br...@xbc.nu>.
Glenn A. Thompson wrote:
> Hey,
> Forgive me for being blunt, but I don't like this config solution at all.
> We are going to add a config option for every little thing for every
> fs type? .... Bah!
Perhaps, perhaps not. For "svnadmin create", we'll probably have both:
an option for every little thing, and an option to read other options
from a config file. There's nothing wrong with being flexible.
> My solution, which I'm in the process of getting back up-to-date, is
> more flexible.
> I use the svn_config_t structure which is loaded by svnadmin using
> svn_config_read.
Where do you read the config file(s) from, if there's no FS or
repository yet?
> It gets passed opaquely from avnadmin all the way to the fs
> initializer in a FS implementation.
> Only the administrator and the affected code portions need to know
> about specific options.
> I also have extensions (as part of the first SQL solution) to the
> svn_config_t methods. My SQL statement support code makes extensive
> use of config files.
>
> Please consider a different route:-(
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.
--
Brane Čibej <br...@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
Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include
libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos
Posted by "Glenn A. Thompson" <gt...@cdr.net>.
Hey,
Forgive me for being blunt, but I don't like this config solution at all.
We are going to add a config option for every little thing for every fs
type? .... Bah!
My solution, which I'm in the process of getting back up-to-date, is
more flexible.
I use the svn_config_t structure which is loaded by svnadmin using
svn_config_read.
It gets passed opaquely from avnadmin all the way to the fs initializer
in a FS implementation.
Only the administrator and the affected code portions need to know about
specific options.
I also have extensions (as part of the first SQL solution) to the
svn_config_t methods. My SQL statement support code makes extensive use
of config files.
Please consider a different route:-(
If you want to see in better detail what I'm talking about, please go to
http://www.cdrguys.com/subversion/fspatch.4.gz
and search for scn_config_t. This was just the start. I was trying to
keep my patch size down:-)
I'm pretty sure I posted about this before but I'll go check.
Thanks,
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org