Re: [GSoC update extra!] git-remote-svn: Week 8

[Jonathan Nieder <jrnieder@gmail.com>]

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