Jonathan Nieder [off-list ref] writes:
Date: Fri, 10 Dec 2010 04:21:35 -0600
Prepare to use mark :5 for the commit corresponding to r5 (and so on).
1 billion seems sufficiently high for blob marks to avoid conflicting
with rev marks, while still leaving room for 3 billion blobs. Such
high mark numbers cause trouble with ancient fast-import versions, but
this topic cannot support git fast-import versions before 1.7.4 (which
introduces the cat-blob command) anyway.
Hmm, 1G+3G split? Will we have HIGHMEM option someday? ;-)
How confident are you that you will never need more than two classes later
and you will never need to split the larger space again?
If you are not, and if the topic is to introduce incompatible output,
would it be wiser to be even more forward looking and introduce different
classes of marks with a backward incompatible syntax, perhaps like using
":\d+" for anything, and using ":[a-zA-Z0-9]+:\d+" for some application
specific "class" of objects that is specifed by the [a-zA-Z0-9]+ part?
Hi,
Junio C Hamano wrote:
Hmm, 1G+3G split? Will we have HIGHMEM option someday? ;-)
How confident are you that you will never need more than two classes later
and you will never need to split the larger space again?
If you are not, and if the topic is to introduce incompatible output,
would it be wiser to be even more forward looking and introduce different
classes of marks with a backward incompatible syntax, perhaps like using
":\d+" for anything, and using ":[a-zA-Z0-9]+:\d+" for some application
specific "class" of objects that is specifed by the [a-zA-Z0-9]+ part?
That sounds very sensible (and I'd be happy to see something like
that).
In this particular case a later patch ("vcs-svn: eliminate repo_tree
structure") gets rid of the blob marks so the split is temporary.
Perhaps a paragraph added to the change description would clear it up.
A later patch will eliminate the blob marks altogether.
For the "vcs-svn: eliminate repo_tree" patch:
Rely on fast-import for information about previous revs.
This requires always setting up backward flow of information,
even for v2 dumps. On the plus side:
- No more need to include blobs in the marks table.
- Given one dump that picks up where another left off, svn-fe
can continue the import. Use
git fast-import --relative-marks \
--export-marks=svn-revs \
--cat-blob-fd=3 3>backchannel
for the first import and
git fast-import --relative-marks \
--import-marks=svn-revs \
--export-marks=svn-revs \
--cat-blob-fd=3 3>backchannel
for later ones.
- It simplifies the code by quite a bit and opens the door
to further simplifications.
Thanks for some clarity.
Jonathan