[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: Sander Striker <striker_at_apache.org>
Date: 2003-11-05 09:52:52 CET

> From: Garrett Rooney [mailto:rooneg@electricjellyfish.net]
> Sent: Wednesday, November 05, 2003 1:07 AM

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

I'd rather go for all or nothing. Not something based on file size.

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

For 2. we'd need both a fork()ed and a threaded implementation, based
on availability advertised by APR at compile time.

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

Well, I could go for this, but we'd need a default working post-commit
hook that does this, instead of just a template.
> > 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.

I think a working default post-commit hook, which does:
 a) deltification
 b) log cleanup

would be a fair solution.


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