[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: deltification question

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2003-11-24 16:13:22 CET

Karl Chen <quarl@hkn.eecs.berkeley.edu> writes:

> Perhaps it would be more intuitive to name the command "svnadmin
> optimize". Svnadmin optimize would deltify or undeltify each
> revision (as necessary). Each revision could have flags for
> whether to optimize for space or speed. A post-commit hook might
> run "svnadmin optimize -r HEAD".

First of all, if customizing the deltification preferences of your
repository becomes this complex, then the functionality will be moved
out of svnadmin altogether and into a new binary, 'svntunefs'.

Secondly, "perhaps"..."could"..."might".... The eleventh hour is not
such a fine time for hypothesizing.

For right now (and probably until 1.0 is out the door), please don't
waste any more time on this topic. People have run Subversion
repositories for three years now without complaining of the need for
this degree of control over their repositories. Our recent move of
the deltification action out into a post-commit svnadmin command
doesn't change the results of that action a single bit. In fact, had
we been able to portably make this post-commit deltification occur
using a threading mechanism instead of a hook script, and thus
avoiding causing a stir in the administrator workflow, I daresay none
of this chatter would have started up again.

In other words, just because we've given you a little bit of control
over when deltification occurs doesn't mean you actually need that
control. Just do what we tell you to, and when someone can actually
come up with a real use-case for fine-grained fs tuning, we can chat.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Nov 24 16:15:09 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.