Issue #1601 is about making deltification happen automatically again.
The issue is currently marked as 1.1, but recent user feedback
indicates that perhaps it should be in 1.0.
Before SVN 0.33, deltification was done automatically, and in the same
thread/process as the commit. Thus the commit did not complete until
deltification had completed, which could lead to user-visible delay.
Our "solution" was to take deltification out of the internal commit
process, make it available as the command 'svnadmin deltify', and
recommend it in the 'hooks/post-commit.tmpl' file that appears in
newly-created repositories. Further research by Mike Pilato confirmed
that running deltification on each commit, at the time the commit
happens, achieves better space savings than deltifying later.
So I'm thinking: Why don't we take this solution all the way?
Let's make a *live* 'post-commit' hook in new repositories, instead of
'post-commit.tmpl', and have the hook automatically run deltification
on each commit.
We shied away from this solution earlier, because (we said) a
'post-commit' hook program is an inherently system-dependent beast,
which only the repository administrator can adequately set up.
But this isn't really true. In 99% of cases (or more?), the
repository is either on a Unix-y system, or a Windows-y system. For
the former, portability is pretty easy: you can depend on /bin/sh, and
we can determine the path to 'svnadmin' at compile time, based on the
configuration. (Plenty of other programs use this technique). Most
of the text of our current post-commit.tmpl can stay as it is. We'd
just want to uncomment the deltification line, remove the 'nice -2'
bit off the front, and replace the 'svnadmin' binary with an absolute
path if possible.
For Win32, portability is also easy, I think. We just have to produce
a .bat file, and tweak the syntax inside it appropriately. I'm not
sure how to run programs in the background on Windows, but if ever
there was a mailing list competent to solve that problem, this is the
one :-). (If there's no portable way to do it, we can either not
background it, or add some Win32-specific switch to svnadmin that
allows it to put *itself* into the background.)
So I don't think it's so hard to create hook scripts that can run
simple commands reliably. Just because a hook script *can* be very
system-dependent doesn't mean it must be.
Nor am I bothered by the prospect of a couple of system-dependent
conditionals in repos.c:create_hooks(). It seems a small price to pay
to solve issue #1601.
And the nice thing is that now every repository would start out with a
real post-commit hook, so a harried repository administrator can
simply add or uncomment stuff (ahem, such as a logfile cleanup
command) in an already-existing script, rather than go find the
template, copy it over, chmod +x, blah blah.
I'll do this, with a little help for some of the Windows stuff, if we
agree it's the thing to do. I just want to make sure I'm not missing
any serious problems.
-Karl
References:
http://www.contactor.se/~dast/svn/archive-2003-11/0114.shtml
http://www.contactor.se/~dast/svn/archive-2003-11/0417.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 15 07:46:23 2003