author | Shawn O. Pearce <spearce@spearce.org> | |
Tue, 16 Jan 2007 05:33:19 +0000 (00:33 -0500) | ||
committer | Shawn O. Pearce <spearce@spearce.org> | |
Tue, 16 Jan 2007 05:33:36 +0000 (00:33 -0500) | ||
commit | 0ea9f045f4eaa1d37c6b318d9d6849a4f447b997 | |
tree | 98aba83b9f0d7b489ca44a0e19a5e8ec44cb507f | tree | snapshot |
parent | 5d6f3ef6413172388ee5e6090afe9802a30a59f0 | commit | diff |
Use uintmax_t for marks in fast-import.
If a frontend wants to use a mark per file revision and per commit
and is doing a truly huge import (such as a 32 GiB SVN repository)
we may need more than 2**32 unique mark values, especially if the
frontend is unable (or unwilling) to recycle mark values. For mark
idnums we should use the largest unsigned integer type available,
hoping that will be at least 64 bits when we are compiled as a 64
bit executable. This way we may consume huge amounts of memory
storing our mark table, but we'll at least be able to process
the entire import without failing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a frontend wants to use a mark per file revision and per commit
and is doing a truly huge import (such as a 32 GiB SVN repository)
we may need more than 2**32 unique mark values, especially if the
frontend is unable (or unwilling) to recycle mark values. For mark
idnums we should use the largest unsigned integer type available,
hoping that will be at least 64 bits when we are compiled as a 64
bit executable. This way we may consume huge amounts of memory
storing our mark table, but we'll at least be able to process
the entire import without failing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import.c | diff | blob | history | |
git-compat-util.h | diff | blob | history |