Ramkumar Ramachandra wrote: > David and I felt that the chatlog was > valuable enough to go on the Git mailing list for later reference, so > here it is. Thanks. :) > <artagnon> SRabbelier: Background -- I generated a delta dumpfile > fine. barrbrain's exporter can't build full text from that, and I > can't do it in my client either. We are looking for some kind of > filesystem -- the Git store is the answer. Can we import revisions > one by one through fast-import and ask Git to generate the full > text? Ah, this is something I was worried about with respect to persistence. Git has all the blobs and all the trees, so except for the mapping between marks, subversion revs, and git revs, svn-fe does not need to persist much data at all. Of course, that requires that the fast-import stream is going directly to git. fast-import streams can be used by other VCSes, too, but that problem can be addressed later, I think. > <barrbrain> so, if you have pipes to fast-import and cat-file > --batch, can you read-write from the repo safely? > <SRabbelier> barrbrain: yes, git is concurrency safe > <barrbrain> what about the timing issue - if I write to fast import > the blob might be delayed in a buffer somewhere > <SRabbelier> barrbrain: I think what we'll need to do is to extend > fast-import to also write the object names to stdout > <SRabbelier> barrbrain: as soon as it's done writing the object FWIW, I like the idea. If you want to keep stdout unpolluted, this could work like git fast-import --print-marks=<fd> We would have to make sure output to the fd is always flushed to prevent deadlock. > <barrbrain> I think I've lost track of which pipe goes where Yeah. > <SRabbelier> ask Shawn if he's ok with having git-fast-import learn a new '--print-marks' flag > <SRabbelier> if so, I'll get on that :) Thanks for the insights. Regards, Jonathan -- 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