C. Michael Pilato wrote:
>"Glenn A. Thompson" <gthompson@cdr.net> writes:
>
>
>
>>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.
>>
>>
>
>Oh. Actually, my latest plan involves a new binary, 'svntunefs',
>which can use subcommands to tune things in particular ways.
>
cool.
>
>
>
>>>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.
>>
>>
>
>I must be missing something, because I *know* you aren't advocating
>having a program calling functions in libsvn_fs that aren't exposed
>via an API.
>
>
No I'm advocating pulling it out of svn_fs.h. But I'll drop it now.
Be warned I will make another attempt to move it:-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 9 16:14:48 2003