Hi, * Shawn O. Pearce [07-03-07 10:59:29 -0500] wrote:
I thought that hg stored file revisions such that each source file (e.g. foo.c) had its own revision file (e.g. foo.revdata) and that every revision of foo.c was stored in that one file, ordered from oldest to newest? If that is the case why not strip all of those into fast-import up front, doing one source file at a time as a huge series of blobs and mark them, then do the commit/trees later on using only the marks?
Or am I just missing something about hg?
I don't want to use anything except the hg mecurial API so that in theory the importer could work even for remote hg repositories.
But the "blob feed" approach doesn't seem perfectly right to me especially for incremental imports. There would have to be state files and internal tables telling what revisions of what files there are with what content. With thousands of files I think this gets quite messy to find even the minimum set to start of with for an incremental import. Also, you can already specify up to which revision to import so it would get even more complicated.
bye, Rocco -- :wq! - 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