git fast-import/fast-export

git fast-import/fast-export

[Sverre Rabbelier]

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

-- 
Cheers,

Sverre Rabbelier

Re: git fast-import/fast-export

[Johannes Schindelin]

Hi,

On Sat, 6 Mar 2010, Sverre Rabbelier wrote:

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

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,

Re: git fast-import/fast-export

[Junio C Hamano]

Sverre Rabbelier <srabbelier@gmail.com> writes:

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

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?

Re: git fast-import/fast-export

[Sverre Rabbelier]

Heya,

On Sat, Mar 6, 2010 at 20:02, Junio C Hamano <gitster@pobox.com> wrote:
> 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.

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

-- 
Cheers,

Sverre Rabbelier

Re: git fast-import/fast-export

[Shawn O. Pearce]

Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Sat, Mar 6, 2010 at 20:02, Junio C Hamano <gitster@pobox.com> wrote:
> > 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.
> 
> 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..

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.

-- 
Shawn.

Re: git fast-import/fast-export

[Sverre Rabbelier]

Heya,

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

Why is that a bad idea?

> I guess I can give my blessing to relicense anything in fast-import
> that I've written from GPLv2 to GPLv2 or v3.

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

> But as Dscho points
> out, there are many authors in even the parsing code.  You will
> need to get consent from all of them.

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

-- 
Cheers,

Sverre Rabbelier