Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Integrate libvcs-svn with libgit2 #1201

Closed
barrbrain opened this Issue Jan 7, 2013 · 8 comments

Comments

Projects
None yet
4 participants
Contributor

barrbrain commented Jan 7, 2013

There is a 2-clause BSD licensed library, vcs-svn, embedded in git-core authored largely by myself and Jonathan Nieder, @jrn. It provides an interface to consume a subversion dump stream and drive a sequence of git commits. In git-core, it consumes the bi-directional interface of git fast-import. I have begun working on adapting the stand-alone upstream library that it is based on to drive the libgit2 APIs. If there is interest in baking this functionality into libgit2, I would like to do so. See https://github.com/barrbrain/svn-dump-fast-export/tree/libgit2 for my porting effort thus far.

jrn commented Jan 7, 2013

Hi,

David Michael Barr wrote:

There is a 2-clause BSD licensed library, vcs-svn, embedded in
git-core authored largely by myself and Jonathan Nieder, @jrn. It
provides an interface to consume a subversion dump stream and drive
a sequence of git commits. In git-core, it consumes the
bi-directional interface of git fast-import. I have begun working on
adapting the stand-alone upstream library that it is based on to
drive the libgit2 APIs.

Sounds good to me. It might be a nice opportunity to clean up
interfaces. Would the result still be usable with fast-import when
built with the right flags?

jrn commented Jan 7, 2013

Jonathan Nieder wrote:

Sounds good to me. It might be a nice opportunity to clean up
interfaces. Would the result still be usable with fast-import when
built with the right flags?

I shortcut the development effort by bypassing translating to and from
fast-import. However, some of the adaptor code I wrote could also
serve as the basis for a fast-import API for libgit2.

David Michael Barr

jrn commented Jan 7, 2013

David Michael Barr wrote:

I shortcut the development effort by bypassing translating to and from
fast-import.

At runtime that's the right behavior anyway. Ideally there would be a
simple shared API (like the current fast_export.h) representing how
vcs-svn interacts with the target repository and multiple
implementations of that API:

fast_export_libgit2.c
fast_export_fast_import.c
...

At compile time one would be chosen. If someone wants to be able to
switch between backends at runtime, that's their problem. ;-)

jrn commented Jan 7, 2013

I had hoped to maintain a compile-time switch when I started hacking.
However, I had to make a handful of changes to the layers above.
I could probably unify the interfaces by separating some of the calls
into begin/end pairs.
For reference, my WIP is at svn-dump-fast-export/libgit2 [1].

[1] https://github.com/barrbrain/svn-dump-fast-export/tree/libgit2

David Michael Barr

Member

martinwoodward commented Jan 7, 2013

Do you think it would make sense to create a new BSD license stand-alone project (libvcs-svn) and make Git and maybe LibGit2 consumers of this? (A bit like what vmg did with the Clar test framework in LibGit2) That way it will be nice and clear to any contributors that the libvcs-svn project that they are contributing to is a BSD licensed module and not accidentally think that they were contributing under the GPLv2 of core Git or the GPLv2+Linking Exception of LibGit2? It also means that there is one master upstream location for contributions to go to that core Git and LibGit2 are consumers of and can pull in fixes when it most make sense to those projects.

If you wanted to do this, it would be worth mailing all the people who had committed patches to vcs-svn inside core Git's directory structure and make sure they were happy with that arrangement first.

Contributor

barrbrain commented Jan 7, 2013

@martinwoodward, not to worry, what you describe is precisely barrbrain/svn-dump-fast-export. It originated as an independent project and care was taken to ensure the license was well documented. Of all the names that have been bestowed upon it, libvcs-svn seems to have stuck the most. The stub frontend was known as svn-fe, the core logic became git.git:vcs-svn. I do my best to keep the projects synchronised but there is still some lag from when the last Summer of Code project was merged downstream.

Contributor

barrbrain commented Jan 7, 2013

I have created libvcs-svn as a new home for the core library. It contains only the core code; no tests, compatibility library, or front-end.

Member

arrbee commented Nov 15, 2013

Not much going on with this - let's close for now and reopen if anyone decides to pursue this in the future. Thanks David!

@arrbee arrbee closed this Nov 15, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment