Re: git fast-import/fast-export

Heya,

As you can read on the wiki [0] I am hoping to mentor a GSoC student this year to work on git-remote-svn, a remote-helper for svn implemented in C. If successful git will be able to work natively with svn repositories, no offense to Eric, but git-svn is a tad sub-optimal ;). To do this I think the best way to go forward is to implement the helper by hooking up a fast-import/fast-export frontend to libsvn. Since it will be implemented in C (partially for speed, but also so that it will be usable on Windows as well), the current fast-import.c and builtin-fast-export.c could be of great use. Neither files have an explicit license, (although builtin-fast-import.c says copyright by Dscho) which puts them under the GPLv2. The libsvn bindings are apache licensed, so we need something licensed either under the apache license, or something compatible with that.

So my question, would it be possible to relicense fast-import.c and builtin-fast-export.c under "GPLv2 or later" instead of the current "GPLv2"? That way we can use (parts of) the code in the svn helper, which will (probably) be licensed as "GPLv2 or later" as well.

[0] http://git.wiki.kernel.org/index.php/SoC2010Ideas#A_remote_helper_for_svn

Hi,

On Sat, 6 Mar 2010, Sverre Rabbelier wrote:

Sure, as far as my parts go, I am fine even with BSD.

Unfortunately, git shortlog shows 18 different authors for fast-export, and blame still shows 17 surviving. I fear you have to ask them all.

The situation is worse with fast-import, with 40 and 36 authors, respectively.

Ciao,

Sverre Rabbelier <srabbelier@gmail.com> writes:

Isn't fast-import designed to be used as a downstream side of a pipe that is fed by an independent program you write (and may link with libsvn)? It wouldn't care what license that data producer program is distributed under.

On the fast-export side the issue should ideally be the same. Your new program that may link with libsvn reads from the datastream that comes from the git repository via pipe as an independent process to propagate the changes to the subversion side.

You may need to have/keep additional info on commits for roundtrip, but that is between the part of your program that feeds fast-import and the other part of your program that consumes the output from fast-export. fast-import may need to be told to export mark, and you pick them up to see what commits resulted on the git side from what you fed it, and later use that information when reading from fast-export to propagate new things back to subversion side. No?

Heya,

On Sat, Mar 6, 2010 at 20:02, Junio C Hamano <gitster@pobox.com> wrote:

Yes, I'm not worried about using the 'git-fast-import' or the 'git-fast-export' binary, I want to use-and-modify the parsing code to work as a fast-import/fast-export frontend to svn _on top_ of using those binaries..

Sverre Rabbelier <srabbelier@gmail.com> wrote:

Oh.  Yuck.

I guess I can give my blessing to relicense anything in fast-import that I've written from GPLv2 to GPLv2 or v3. But as Dscho points out, there are many authors in even the parsing code. You will need to get consent from all of them.

Heya,

On Sat, Mar 6, 2010 at 22:43, Shawn O. Pearce <spearce@spearce.org> wrote:

Why is that a bad idea?

Ok, if nothing else we can use one of the earlier versions ;).

Right, I figured I'd first get an OK from the top N before spamming 40 people :).