Re: Idea for git-fast-import

[Michael Haggerty <mhagger@alum.mit.edu>]

Shawn O. Pearce wrote:
> Michael Haggerty <mhagger@alum.mit.edu> wrote:
>> Also, is there a big cost to using "not-quite-consecutive" integers as
>> marks?  cvs2svn's CVSRevision IDs are intermingled with IDs for
>> CVSBranches and CVSTags, so the CVSRevisions alone probably only pack
>> the ID space 5%-50% full.
> 
>> In fact, if there is a big cost to "not-quite-consecutive" integers,
>> then I withdraw my request for separate mark namespaces, since I would
>> have to reallocate mark numbers anyway :-)
> 
> See above.  5% full is really bad, because you are probably going to
> allocate nearly every block in the directory, and only fill each leaf
> block at 5% full.  50% full is actually reasonable, as it means marks
> are only costing you about 2 pointers on average (8 or 16 bytes).

OK, then, never mind.  As I mentioned, it is not a big deal to have
cvs2svn generate a separate integer series for marks.  If comments are
implemented, then the debugging disadvantage is also quite minor.

>> Another thing that might help with debugging would be a "comment"
>> command, which git-fast-import should ignore.  One could put text about
>> the source of a chunk of git-fast-import stream to relate it back to the
>> front-end concepts when debugging the stream contents by hand.
> 
> This is an awesome idea, especially when combined with having a
> buffer of the last few commands that fast-import saw right before
> it crashed.  I'll see what I can do.

Thanks!

Michael