...
>So many options. So potentially nasty an interface.
>
>But I'm working on it.
>
>The gears are turning.
>
>I can hear the ... uh-oh! That's a grindstone that I'm lying on!
>
>
Given all the possibilities you mention I question more and more, the
benefit to putting it back into svnadmin *if* everyone agrees that
Branes "separate program" idea is the long term solution. All the work
is being done in the FS code anyway. The role svnadmin plays can easily
be placed in another main. See below.
>
>
>>Ignoring the unsupported issue, I like what you propose. One thing
>>though, IMHO svn_fs_deltify should not be part of the *core*
>>svn_fs.h API. Would you consider *not* putting svn_fs_deltify back
>>in to svn_fs.h? I'd prefer seeing it in some sort of maintenance
>>header file.
>>
>>
>
>I know where you're heading here. What business is it of the outside
>world to know a darned thing about the storage mechanism used by the
>database? And I hear you, I really do. But I see no compelling
>reason for this not to go in svn_fs.h. It must be a public interface,
>
Why? The only program using it is a maintenance program.
>and there's no reason to introduce a new public interface file for a
>single function. Would you feel better if it were called
>svn_fs_deltify_berkeley()?
>
Absolutely not! :-)
Since I seem to be on the loosing side of the argument for keeping it
out of svn_fs.h. How about it something like svn_fs_optimize or
svn_fs_vacuum, or svn_fs_tune.
gat
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 8 16:09:56 2003