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

Re: issue #1573: fs deltification causes delays

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2003-11-05 01:06:49 CET

On Nov 4, 2003, at 10:01 AM, C. Michael Pilato wrote:

> kfogel@collab.net writes:
>> There are various proposed solutions in the issue. But for now, I'd
>> like to talk just about solutions we can implement before 1.0 (i.e.,
>> before Beta, i.e., before 0.33 :-) ). The two that seem most
>> realistic are:
>> 1. Prevent deltification on files over a certain size, but create
>> some sort of out-of-band compression command -- something like
>> 'svnadmin deltify/compress/whatever' that a sysadmin or cron job
>> can run during non-peak hours to reclaim disk space.
>> 2. Make svn_fs_merge() spawn a deltification thread (using APR
>> threads) and return success immediately. If the thread fails to
>> deltify, it's not the end of the world: we simply don't get the
>> disk-space savings.
> 3. Never do deltification of any sort in the filesystem code, and
> create an out-of-band compression command that can be run as a
> post-commit hook.

I really don't find the idea of having to run separate commands to get
deltification very intuitive. If I was a new user, I would be shocked
if deltas were not used by default. If anything, this should only be
enabled for files over a certain size, so that everyone does not need
to pay the price.

> I say all this to promote the idea that it isn't too much to ask of a
> repos administrator to run some out-of-process deltification routine
> -- even per-commit -- because if they are truly concerned about disk
> space, they'll already have some out-of-process log-file cleanup
> process. And if you have a cronjob/post-commit hook to cleanup
> logfiles, what's an extra line in that script to deltify?

People already freak when they find out about the logfiles stuff. I
don't like the idea of adding more administrative overhead if it can be


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Nov 5 01:07:31 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.