When you say toolchain, are you referring to the compiler
and associated libraries or are you referring to OS programs
such as ls, md5, cat, etc or both?
The reason that I ask is that I have been playing different
scenarios using git 1.5.3.5 under MacOSX 10.4.10 mostly
all day and every time that
A) a file approaches or exceeds 2gig on an 'add', it
results in:
fatal: Out of memory? mmap failed: Cannot allocate memory
B) the repository size less the .git subdirectory approaches
4gig on a 'fetch' it results in:
Resolving 3356 deltas...
fatal: serious inflate inconsistency: -3 (unknown compression method)
fatal: index-pack died with error code 128
fatal: Fetch failure: ../rmwHtmlOld
Under B, building the initial repository works fine.
(I added a patch the Linus Torvalds gave out when a previous inflate
problem
was being researched.) Also, I have been looking in the source
in particular in builtin-add.c builtin-pack-objects.c and associated
headers
and see int and unsigned long being used a lot, but not any unsigned
long
longs. I have been testing on my laptop which has a 32-bit Intel
Core Duo.
Also, I have run the same tests on a dual quad-core Intel processor
which is 64 bit, (but not sure that Apple uses the 64 bits in
10.4.10). I
get the same results as above.
The zlib is at the latest revision of 1.2.3 and gcc is at 4.0.1
which from what I can tell supports large files, because 'off_t' is 8
bytes
which is the size used for a 'stat' file size.
I am just wondering if these size limitations exist for MacOSX
or maybe I am doing something wrong (which is probably
the case).
On Nov 10, 2007, at 12:13 AM, Nicolas Pitre wrote:
On Fri, 9 Nov 2007, bob wrote:
When a repository is packed such as for a clone or fetch, is there
just one
pack file created that is used for the transfer?
Yes.
And modern Git is able to handle packs larger than 4GB too,
assuming it
is compiled using a toolchain with large file support.
Nicolas
-
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
