On Wed, Oct 22, 2008 at 12:37 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Wed, Oct 22, 2008 at 9:32 AM, David Glasser <glasser_at_davidglasser.net> wrote:
>> On Wed, Oct 22, 2008 at 5:34 AM, Greg Stein <gstein_at_gmail.com> wrote:
>>...
>>> Later, the idea of researchers surfaced, and that they'd be trying to
>>> store file pairs with the same hash. I grant your scenario is valid.
>>...
>> It's still a regression vs 1.5. Can you at least acknowledge that?
>
> I did; see above :-)
>
> That said, I disagree that it is a common enough use case to go for a
> double-compute which burns 99.9% of our users. IOW, I'm more than
> willing to tell 0.01% of our users to spend a bit of extra work, in
> order to use Subversion.
>
> From day one, we said, "let's solve the 80-90 percent problem WELL,
> and make the rest doable." Well... those researchers have
> alternatives: store the matched pair in a .tar file. Or gzip it. Or
> hell... rot13 to the rescue!!
OK. But you know that the user experience is "files silently get
changed", not "errors happen", right?
(And I wouldn't be shocked if, say, OpenSSL needed to distribute such
files in their test suite. etc.)
>> Also, if double-hash-computation is such a horrible thing, then why is
>> it OK for fs_base to use it but not fs_fs?
>
> Never said it was okay. I raised the issue when that commit arrived,
> and (iirc) the feedback was "that is just temporary code". My own
> experience, and Ivan also confirmed: the server can often be
> CPU-bound, so an extra hash computation is a Bad Thing(tm), and we
> shouldn't do it.
*nod*, reasonable. I'd still argue that (for FSFS) rep-sharing seems
to be a net loss, though.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-10-22 22:04:33 CEST