Shawn O. Pearce wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> 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 - 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
