[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: rev 5119 - in trunk/subversion: svnadmin include libsvn_fs tests tests/libsvn_fs tests/clients/cmdline/svntest libsvn_repos

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-02-26 22:05:24 CET

Philip Martin wrote:

>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.
>
Because we expect to have all sorts of FS back-ends someday, and each
would presumably use completely different configuration options.
Exposing the configuration structure like that -- even if only through
its setter/getter API -- is a bad idea in this case, because it would
add dependencies between the different FS back-ends instead of isolating
them.

[snip]

>Hard-coded strings and magic numbers :-(
>
>
So? I thought the whole point was to make hacking harder, so that people
got an education while fiddling with Subversion. ;-)

-- 
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 Wed Feb 26 22:06:18 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.