brane@tigris.org writes:
> Author: brane
> Date: 2003-02-26 13:52:01 -0600 (Wed, 26 Feb 2003)
> New Revision: 5119
>
> Modified:
> trunk/subversion/include/svn_fs.h
> trunk/subversion/include/svn_repos.h
> trunk/subversion/libsvn_fs/fs.c
> trunk/subversion/libsvn_fs/fs.h
> trunk/subversion/libsvn_repos/repos.c
> trunk/subversion/svnadmin/main.c
> trunk/subversion/tests/clients/cmdline/svntest/main.py
> trunk/subversion/tests/fs-helpers.c
> trunk/subversion/tests/libsvn_fs/fs-test.c
> Log:
> Added a mechanism for sending runtime configuration data to the filesystem,
> an option to svnadmin and the FS to switch off fsync on BDB transaction commit,
> and changed all tests to use this option.
>
> * subversion/include/svn_fs.h (svn_fs_new): Add new parameter 'fs_config'.
> * subversion/include/svn_repos.h (svn_repos_create): Likewise.
Another hash. Why are we passing data as strings in a hash? Why not
simply pass a normal C structure? If you don't want to expose the
structure then make it an opaque type with function to set the value.
I guess my question applies to the auth stuff as well. Why are these
hashes popping up all of a sudden? What's the advantage to using a
hash over a C structure? One of the problems of using a hash is that
every time you want to add a new data item, you have to check that key
is not already being used. The compiler does not care if there is a
clash, whereas with a normal C interface a clash is impossible.
A hash also loses out as soon as the data gets more complicated than a
flag or string. Suppose we want to pass a number, do we first convert
it to a string to store it in the hash, and then convert it back to a
number when we want it? What do we do if we get "foobar" when
expecting a number? We will need to use special number parsing code
each time. Or do we pass the number directly, rather than passing
it's string representation? That would make the consequences of a key
clash with something expecting to get a string even more serious.
> Modified: trunk/subversion/svnadmin/main.c
> ==============================================================================
> --- trunk/subversion/svnadmin/main.c (original)
> +++ trunk/subversion/svnadmin/main.c Wed Feb 26 13:52:07 2003
> @@ -83,7 +83,8 @@
> svnadmin__on_disk_template,
> svnadmin__in_repos_template,
> svnadmin__ignore_uuid,
> - svnadmin__force_uuid
> + svnadmin__force_uuid,
> + svnadmin__bdb_txn_nosync
> };
>
> /* Option codes and descriptions.
> @@ -125,6 +126,9 @@
> {"force-uuid", svnadmin__force_uuid, 0,
> "set repos UUID to that found in stream, if any."},
>
> + {"bdb-txn-nosync", svnadmin__bdb_txn_nosync, 0,
> + "disable fsync at database transaction commit [Berkeley DB]."},
> +
> {NULL}
> };
>
> @@ -137,7 +141,8 @@
> {"create", subcommand_create, {0},
> "usage: svnadmin create REPOS_PATH\n\n"
> "Create a new, empty repository at REPOS_PATH.\n",
> - {svnadmin__on_disk_template, svnadmin__in_repos_template} },
> + {svnadmin__on_disk_template, svnadmin__in_repos_template,
> + svnadmin__bdb_txn_nosync} },
>
> {"createtxn", subcommand_createtxn, {0},
> "usage: svnadmin createtxn REPOS_PATH -r REVISION\n\n"
> @@ -216,6 +221,7 @@
> svn_boolean_t incremental; /* --incremental */
> svn_boolean_t follow_copies; /* --copies */
> svn_boolean_t quiet; /* --quiet */
> + svn_boolean_t bdb_txn_nosync; /* --bdb-txn-nosync */
> enum svn_repos_load_uuid uuid_action; /* --ignore-uuid,
> --force-uuid */
> const char *on_disk;
> @@ -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");
Hard-coded strings and magic numbers :-(
--
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 26 21:50:07 2003