[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: <kfogel_at_collab.net>
Date: 2003-11-07 22:45:15 CET

Two things seem pretty clear from this discussion:

   1. The status quo is useless, because the space savings of
      deltification are undone by the additional BDB logfiles.
      (Unless you run log cleanup on a regular basis, of course.)

   2. The status quo is harmful, because it causes users to wait
      longer for commits to return, especially with large files.

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 am *not* proposing this as an ideal solution, merely one better than
what we have now. Right now, we have deltification, but it doesn't
help unless the admin takes extra steps. If they have to take extra
steps anyway, we can make the deltification be part of that and thus
avoid the user-wait problem.

For the long run, I think the best solution comes from Brane:

> Why not? Anyway, we don't have to put this into "svnadmin", we can
> create a custom binary (e.g., svndeltify) and simply demand that it _is_
> installed in a place where Apache, svnserve, etc. can find it. It's no
> more complicated than installing mod_dav_svn.so, and it's a _lot_ easier
> than making default hook scripts or cron scripts that work on all platforms.

In other words, Subversion itself would still drive deltification,
unconditionally, but we would use portable APR methods to fire it off
as a background process (maybe APR can even 'nice' it on some
platforms?) so the commit could finish right away.

That's all great, but it's a bit of work, and if it happened in 1.1
that wouldn't be a disaster, because there's no compatibility step
(and no real harm if cron jobs try to do work where there's none to be
done, for a while after the upgrade). And, the immediate change I'm
proposing is just one step on the way to Brane's solution anyway.
None of the work would need to be undone.

Is this crazy, or practical?

(These are not mutually exclusive, I suppose, but FWIW, Mike and Ben
also thought the latter.)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Nov 7 23:26:38 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.