Sam Vilain wrote:
> Michael Haggerty wrote:
>>> ++
>>> +Note that due to current internal limitations, you may not make marks
>>> +with a higher number than 1048575 (2^20-1).
>>>
>>> * A complete 40 byte or abbreviated commit SHA-1 in hex.
>>>
>> Oh. Um. That is an awkwardly small number nowadays.
>>
>> cvs2svn has been used for repositories with O(2^20) distinct file
>> revisions (KDE, Mozilla, NetBSD, ...). So this limit will likely be too
>> small for some users.
>
> Right. But, if you're not making the importer you write for a
> conversion of that size restartable, you're insane. So, marking more
> than 1Mi *marks* in a single gfi session might not be so vital.
Well, call me insane then. Because there *are* no bulletproof
incremental CVS importers, and it would be a lot of work to write one.
(git-cvsimport doesn't count because it is far from bulletproof.) So it
is reasonable to choose a high-quality one-time conversion over a broken
restartable conversion.
>> While I'm at it, let me also renew my suggestion that git-fast-import
>> use separate namespaces ("markspaces", so to speak) for file content
>> marks and for commit marks. There is no reason for these distinct types
>> of marks to be located in a shared space of integers.
>
> There is a reason, it's because they're both just object IDs. Is it
> really that much of a drag? I know what you mean though, it meant for
> my code I had to keep track of which type each mark was.
That's exactly my point. That's at least two of us then who have had
extra work to merge two separate ID concepts into a single integer
sequence. It's not a big deal, but it would be convenient if
git-fast-import allowed the sequences to overlap.
Michael
--
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
