I'd actually like to see this a per-repository configurable option.
If the post-commit hook for this cannot be automatically installed, which I suspect is not a feasible option due to platform dependancies and not knowing in advance what kind of scripting-languages are installed, then having no automatic deltification means a much larger barrier-to-entry for the inexperienced, new user who wants as much as possible everything automatic but does want version control.
Telling people: 'install a script as a hook, make up your own here's a sample, or svn will eat diskspace like there's no tomorrow' is not a good way to attract newbie type of users. The same sort of users who will access their repositories via 'file://' urls because you don't need to do any kind of setup for that, no servers to install etc.
And I think that that's a bad thing.
regards,
--Tim
-----Original Message-----
From: kfogel@newton.ch.collab.net [mailto:kfogel@newton.ch.collab.net]On
Behalf Of kfogel@collab.net
Sent: vrijdag 14 november 2003 7:03
To: Paul Gross
Cc: users@subversion.tigris.org
Subject: Re: Subversion 0.33.0 released.
Paul Gross <paul@grosss.net> writes:
> making a post-commit hook to run it? I tried searching around, but I
> couldn't find a good explanation of what it is or why I need it.
This is something I probably should have explained more in the release
announcement. Well, hopefully people will see it in this thread. In
fact, I'll repeat the important part, just so people see it again:
2. In order to make commits more responsive, repository
deltification is no longer automatic. However, you may want
to run deltification as a background process in your repository
post-commit hook. For example, the new post-commit.tmpl file
recommends 'nice -2 svnadmin deltify "$REPOS" -r "$REV" &'.
What is deltification?
Basically, Subversion stores (or is capable of storing) successive
revisions of a file in compressed form, thusly: the youngest revisions
is stoed in full, then the previous revision is stored as a diff
against that, and the next previous is a diff against the previous,
and so on back to the first revision of the file.
Until 0.33, it did this automatically. Whenever you committed a
change to a file, Subversion would change the storage representation
of the previous revision to be a diff against the new version of the
file, to save space in the repository.
None of this is user visible, of course. When Subversion retrieves a
file from a revision, it undoes any deltification and just hands you
the fulltext.
But unfortunately, there *was* a sense in which it was user-visible:
for large files, or many files, the deltification process could take
so long that it visibly slowed down the commit. (There are various
other complexities here too, such as the fact that the extra database
hits were generating db logfiles, which the administrator would want
to be cleaning up somehow...).
Anyway, we stopped doing deltification as an automatic part of the
commit, and started considering other solutions.
The ideal solution would be to spin off a deltification thread in the
background at the end of the commit, and return immediately to the
user, so the user would see "Committed revision XXX" immediately and
not have to wait for the deltification to finish. However, it turns
out to be difficult to portably run processes in the background.
So for now, what we've done is foisted this responsibility onto the
repository administrator. But we've tried to make it very easy to set
up: we have a command 'svnadmin deltify', and a fairly portable
template for invoking it (in the background) in the post-commit hook.
In conclusion: repository administrators who don't have an infinite
amount of disk space will want to change their post-commit hooks to
run deltification :-).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 14 13:25:35 2003