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