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 <nico@cam.org>
---

OK this should really be the last patch for this topic.

diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
new file mode 100755
index 0000000..3371964
--- /dev/null
+++ b/t/t5302-pack-index.sh
@@ -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 &&
+     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 &&
+     echo 101 >file_101 && tail -c 8k file_100 >>file_101 &&
+     git-update-index --add file_101 &&
+     tree=`git-write-tree` &&
+     commit=`git-commit-tree $tree </dev/null` && {
+	 echo $tree &&
+	 echo $commit &&
+	 git-ls-tree $tree | sed -e "s/.* \\([0-9a-f]*\\)	.*/\\1/"
+     } >obj-list &&
+     git-update-ref HEAD $commit'
+
+test_expect_success \
+    'pack-objects with index version 1' \
+    'pack1=$(git-pack-objects --index-version=1 test-1 <obj-list) &&
+     git-verify-pack -v "test-1-${pack1}.pack"'
+
+test_expect_success \
+    'pack-objects with index version 2' \
+    'pack2=$(git-pack-objects --index-version=2 test-2 <obj-list) &&
+     git-verify-pack -v "test-2-${pack2}.pack"'
+
+test_expect_success \
+    'both packs should be identical' \
+    'cmp "test-1-${pack1}.pack" "test-2-${pack2}.pack"'
+
+test_expect_failure \
+    'index v1 and index v2 should be different' \
+    'cmp "test-1-${pack1}.idx" "test-2-${pack2}.idx"'
+
+test_expect_success \
+    ...
[ message continues ]

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.

-

[ message continues ]

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
-

[ message continues ]

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.

-

[ message continues ]

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.
-

[ message continues ]

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
-

[ message continues ]