Re: 1.3.0 creating bigger packs than 1.2.3

[Shawn Pearce <spearce@spearce.org>]

Linus Torvalds <torvalds@osdl.org> wrote:
> Ok, so that wasn't it, and the new sort order is superior.
> 
> That means that it probably _is_ the delta changes themselves (probably 
> commit c13c6bf7 "diff-delta: bound hash list length to avoid O(m*n) 
> behavior". You can try
> 
> 	git revert c13c6bf7

No effect.
 
> to see if that's it. Although Nico already showed interest, and if you 
> make the archive available to him, he's sure to figure it out.

I sent the URL privately to Nico as I did not want the repository
to be publically available before next Tuesday.

> You can try "--depth=50" (slogan: more "hot delta on delta action"), but 
> it's looking less and less like a delta selection issue, and more and more 
> like the deltas themselves are deproved.

No effect at either 50 or 100.

The more that I think about it the more it seems possible that the
pathname hashing is what may be causing the problem.  Not only did
bisect point to 1d6b38cc76c348e2477506ca9759fc241e3d0d46 but the
directory which contains the bulk of the space has many files with
the same name located in different directories:

	results/MT/Math/10000/0-11-AdjLite.deg
	results/MT/Math/10000/0-12-AdjLite.deg
	...
	results/MT/Math/30000/2-11-AdjLite.deg
	results/MT/Math/30000/2-12-AdjLite.deg
	...
	results/Rand48/Math/10000/2-11-AdjLite.deg
	results/Rand48/Math/10000/2-12-AdjLite.deg
	...
	results/Rand48/Math/30000/2-11-AdjLite.deg
	results/Rand48/Math/30000/2-12-AdjLite.deg
	...

For example the name '0-11-AdjLite.deg' occurs in 63 directories and
none of those occurrances are likely to delta against one another
very well.  Also most of these files only have 1 or 2 revisions,
so there is very little per-file history.

-- 
Shawn.