Re: issue #1573: fs deltification causes delays

"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.

> >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.

> >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

See above. svn_fs_tunefs() would likely be the route I'd take.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 8 17:59:35 2003