Re: Idea for git-fast-import
- From
Michael Haggerty <mhagger@alum.mit.edu>
- Date
- Jul 22, 2007, 18:35 UTC
- Message-ID
- <46A3A38D.5020601@alum.mit.edu>
- In-Reply-To
- <20070720072824.GP32566@spearce.org>
Shawn O. Pearce wrote:
Show 14 quoted lines
> 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.
Show 8 quoted lines
>> 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