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

Re: The small commit problem

From: Branko Čibej <brane_at_xbc.nu>
Date: 2003-07-30 06:56:02 CEST

Philip Martin wrote:

>Philip Martin <philip@codematters.co.uk> writes:
>
>
>
>>kfogel@collab.net writes:
>>
>>
>>
>>>Yes, I think it might be time to turn on directory deltification. It
>>>was turned off here, I think:
>>>
>>> ------------------------------------------------------------------------
>>> rev 1043: cmpilato | 2002-01-24 10:03:50 (Thu, 24 Jan 2002) | 12 lines
>>>
>>> Turning off deltification of directory entries lists (should this be
>>> wrapped in #ifdef SVN_FS_DELTIFY_DIR_ENTRIES and made into a
>>> compile-time feature?)
>>>
>>>
>>Hmmm, the code has changed quite a bit since then. Would this be the
>>way to turn it back on?
>>
>>Index: subversion/libsvn_fs/tree.c
>>===================================================================
>>--- subversion/libsvn_fs/tree.c (revision 6607)
>>+++ subversion/libsvn_fs/tree.c (working copy)
>>@@ -1385,7 +1385,7 @@
>> /* If this node has a predecesser, deltify it. */
>> if (noderev->predecessor_id)
>> SVN_ERR (txn_deltify (node, noderev->predecessor_count,
>>- args->is_dir, trail));
>>+ 0, trail));
>>
>> return SVN_NO_ERROR;
>> }
>>
>>
>
>Good news and bad news.
>
>I have been converting the debhelper CVS archive posted a day or so
>ago. It's a 3.5M CVS archive and using the Subversion HEAD it
>converts to a 20M Subversion repository with 1087 revisions, of which
>485 are tags. Using the patch above the Subversion repository size is
>reduced to 13M. If I 'svnadmin dump' bits of the two repositories
>they appear to be the same.
>
>That's the good news, the bad news is that it is extremely slow. If I
>attempt a full dump of the repository, it runs a bit slowly for the
>first 22 revisions, but with the machine using 100% CPU. Around about
>revison 23 the CPU usage drops to near zero and the dump crawls along
>so slowly I have never bothered to let it finish. Dumping the
>revision range 20:40 takes less than 10 seconds without the patch and
>over 4 minutes with the patch. The revision range 520:540 takes 10
>seconds without the patch and over a minute with the patch.
>
>

This is fun. I've had this idea that we're not storing directory info as
efficiently as we could -- in both space and time -- but couldn't find
(and wasn't bothered to look for...) any tangible proof. So it looks
like it's time to rev up the ol' brain again and take a look at the
schema. :-)

-- 
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 Fri Aug 22 09:23:47 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.