From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:03
Nicolas Pitre [off-list ref] writes:
quoted hunk
This is a fairly complete list of tests for various aspects of pack
index versions 1 and 2.
Tests on index v2 include 32-bit and 64-bit offsets, as well as a nice
demonstration of the flawed repacking integrity checks that index
version 2 intend to solve over index version 1 with the per object CRC.
Signed-off-by: Nicolas Pitre <redacted>
---
OK this should really be the last patch for this topic.
@@ -0,0 +1,147 @@+#!/bin/sh+#+# Copyright (c) 2007 Nicolas Pitre+#++test_description='pack index with 64-bit offsets and object CRC'+../test-lib.sh++test_expect_success\+'setup'\+'rm-rf.git+git-init&&+foriin`seq-w100`+do+echo$i>file_$i&&+ddif=/dev/urandombs=8kcount=1>>file_$i&&+git-update-index--addfile_$i||return1+done&&
Is there a way for our tests to be a bit more stable than
urandom? I saw on the first run fsck was OOM-killed, but the
second and subsequent run did not. It's a bit hard to diagnose.
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:03
On Tue, 10 Apr 2007, Junio C Hamano wrote:
quoted
+ for i in `seq -w 100`
+ do
+ echo $i >file_$i &&
+ dd if=/dev/urandom bs=8k count=1 >>file_$i &&
+ git-update-index --add file_$i || return 1
+ done &&
Is there a way for our tests to be a bit more stable than
urandom? I saw on the first run fsck was OOM-killed, but the
second and subsequent run did not. It's a bit hard to diagnose.
The problem here is that I really need large amount of random data that
doesn't compress nor delta between objects.
Hmmm what we need is a random data generator that always produces the
same thing. I'll hack something to replace urandom.
Nicolas
On Wed, Apr 11, 2007 at 08:57:09AM -0400, Nicolas Pitre wrote:
Hmmm what we need is a random data generator that always produces the
same thing. I'll hack something to replace urandom.
Don't hack something, ues the standard reference, the Mersenne Twister.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
PRNGs are the same as cryptosystems, it's very easy to hack up
something and get it very, very wrong. And it's unnecessary, since
there are very good ones available.
OG.
From: Shawn O. Pearce <hidden> Date: 2016-06-15 22:43:03
Olivier Galibert [off-list ref] wrote:
On Wed, Apr 11, 2007 at 08:57:09AM -0400, Nicolas Pitre wrote:
quoted
Hmmm what we need is a random data generator that always produces the
same thing. I'll hack something to replace urandom.
Don't hack something, ues the standard reference, the Mersenne Twister.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
PRNGs are the same as cryptosystems, it's very easy to hack up
something and get it very, very wrong. And it's unnecessary, since
there are very good ones available.
Indeed. But Mersenne Twister doesn't have code to produce a random
file of size X given an initial constant seed of Y, does it?
A small program to produce X random bytes starting with seed Y
still needs to be hacked up.
Probably the smart thing to do here is to embed a copy of MT with
constant seeds so we always get the same data file produced on
every system, no matter what the implementation of the C library's
rand routine is.
Although MT is not GPL. It has its own license, one with a small
advertising clause...
--
Shawn.
From: Nicolas Pitre <hidden> Date: 2016-06-15 22:43:04
On Wed, 11 Apr 2007, Shawn O. Pearce wrote:
Olivier Galibert [off-list ref] wrote:
quoted
On Wed, Apr 11, 2007 at 08:57:09AM -0400, Nicolas Pitre wrote:
quoted
Hmmm what we need is a random data generator that always produces the
same thing. I'll hack something to replace urandom.
Don't hack something, ues the standard reference, the Mersenne Twister.
http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html
PRNGs are the same as cryptosystems, it's very easy to hack up
something and get it very, very wrong. And it's unnecessary, since
there are very good ones available.
Indeed.
Please don't get too excited.
We don't want a full fledged random number generator with a period of
2^30000 that is faster than light and impossible to predict, etc, etc.
The _only_ thing we want is a convenient way to produce large files with
garbage that is neither compressible nor deltifiable, but still
reproducible. And for that matter the Mersenne Twister algo is _way_
too heavy for our needs.
The one that I just implemented basically boils down to:
while (count--) {
next = next * 1103515245 + 12345;
putchar((next >> 16) & 0xff);
}
and that does the job perfectly well.
Nicolas