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