"Glenn A. Thompson" <gthompson@cdr.net> writes:
> Hey,
>
> >I hope these two points will make the following proposal less
> >controversial than it might otherwise be:
> >
> >Let's turn off fs deltification by default, restore the command
> >'svnadmin deltify' from r3920 or thereabouts, and document (both in
> >user documentation and in the post-commit template) how to run both
> >manual deltification and logfile cleanup, with a cron example as well
> >as a hook example.
> >
> I remember this being un-implemented. I did a quick check and
> svnadmin calls svn_fs_deltify which returns
> SVN_ERR_UNSUPPORTED_FEATURE in every revison of deltify.c I looked
> at. Is there some simple "calling of" an existing function that
> resolves this problem? Did I miss something?
No, you didn't miss anything. It was unsupported for what was at the
time a decent reason. Back then, we only every deltified a node
against its successor. Of course, we can't *know* a node's successor
with confidence without a really expensive bit of filesystem
scouring. So, I punted.
Moving deltification out of the commit process does introduce a bit of
theoretical ick, similar to what I ran into svn_fs_deltify() back
then. Say my repository generates 10 new revisions per day, and I
have a script that runs nightly to deltify stuff. Well, what should I
deltify, and against what? I could loop over the 10 revisions and
deltify the predecessors of nodes changed in that revision against the
nodes themselves -- that'd be the easiest thing, and would be the
exact same functionality provided today. Or I could just deltify the
nodes that changed in the revision against the empty string (in other
words, just do compression). Or maybe both. Or I could look for the
paths in HEAD (verifying that if I find an existent thing there, it is
ancestrally related to my node) and deltify against that, falling back
to deltifying against an empty string if I can't find the youngest
successor.
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!
> 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,
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()?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 8 09:18:05 2003