# Re: git fast-import/fast-export 6 messages from 2010-03-06 to 2010-03-06. Participants: Shawn O. Pearce, Johannes Schindelin, Sverre Rabbelier, Junio C Hamano. Thread: https://gitlist.dev/t/22929 ## Sverre Rabbelier, 2010-03-06 15:02 Subject: git fast-import/fast-export Message-ID: URL: https://gitlist.dev/e/fabb9a1e1003060702r671b57f4m9308863f566d5fbd%40mail.gmail.com ``` 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 ``` ## Johannes Schindelin, 2010-03-06 15:29 Subject: Re: git fast-import/fast-export Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.1003061623511.7596%40pacific.mpi-cbg.de In-Reply-To: ``` 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, ``` ## Junio C Hamano, 2010-03-06 19:02 Subject: Re: git fast-import/fast-export Message-ID: <7v3a0di87z.fsf@alter.siamese.dyndns.org> URL: https://gitlist.dev/e/7v3a0di87z.fsf%40alter.siamese.dyndns.org In-Reply-To: ``` Sverre Rabbelier 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? ``` ## Sverre Rabbelier, 2010-03-06 19:05 Subject: Re: git fast-import/fast-export Message-ID: URL: https://gitlist.dev/e/fabb9a1e1003061105u70cf87b8h579fe154a24fb8f0%40mail.gmail.com In-Reply-To: <7v3a0di87z.fsf@alter.siamese.dyndns.org> ``` Heya, On Sat, Mar 6, 2010 at 20:02, Junio C Hamano 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 ``` ## Shawn O. Pearce, 2010-03-06 21:43 Subject: Re: git fast-import/fast-export Message-ID: <20100306214321.GD2529@spearce.org> URL: https://gitlist.dev/e/20100306214321.GD2529%40spearce.org In-Reply-To: ``` Sverre Rabbelier wrote: > On Sat, Mar 6, 2010 at 20:02, Junio C Hamano 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. ``` ## Sverre Rabbelier, 2010-03-06 21:45 Subject: Re: git fast-import/fast-export Message-ID: URL: https://gitlist.dev/e/fabb9a1e1003061345t7e261505q27453ff546e5463b%40mail.gmail.com In-Reply-To: <20100306214321.GD2529@spearce.org> ``` Heya, On Sat, Mar 6, 2010 at 22:43, Shawn O. Pearce 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 ```