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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 20, 2010, 22:19 UTC
Message-ID: <f3271551003201519r61d3b9e5y83691ebb25da3534@mail.gmail.com>
In-Reply-To: <alpine.LNX.2.00.1003201724270.14365@iabervon.org>

Show 5 quoted lines

> 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.

Show 5 quoted lines

> 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