Re: native-git-svn: A Summer of Code 2010 proposal

[Ramkumar Ramachandra <artagnon@gmail.com>]

> The one thing I worry about is that you are proposing to wait a while
> before submitting your changes upstream.  I would suggest pushing
> whatever pieces work to contrib/ early on to get more feedback from
> reviewers and testers.  (I am saying this selfishly, as a potential
> tester.)

Okay, I'll try to get patches integrated immediately then.

> The structure for remote helpers should be that each foreign system has a
> single helper which git can call with instructions on what to do (both for
> foreign-to-git and for git-to-foreign operations). So 3 and 4 have to be
> functions of the same program, and it's probably best for 2 and 5 and
> maybe 1 to also be part of this program.

Right. I only split it up for the purposes of illustration. 3 and 4
will be merged into a program called `git-remote-svn` that will
automatically be invoked when Git encounters an SVN remote. 2 and 5
will be merged into another program `svn-export-import` which can be
thought of as the fusion of svn-fast-export and svn-fast-import.
`git-remote-svn` will invoke it when necessary. And yeah, I don't know
if I want to write the SVN client into `svn-export-import` or leave it
as a separate program.

> So the helper wouldn't be running git-fast-export or git-fast-import,
> unless it was a helper for using git as the foreign system.

Ah. I just realized that :)

> If you're going to work in C, you should look at my Perforce helper. It's
> suitable for mainline inclusion, due to using a free-as-in-beer,
> made-available-without-license-terms C++ library for the Perforce side,
> but may be a better model for a C remote helper than git.py is.

Thanks. I'll have a look. git.py isn't very useful.

Regards,
Ramkumar