[GSoC] Git to SVN bridge

Hi,

Continuing the git-remote-svn effort from two summers ago, I want to complete the Git -> SVN bridge.

Note: This is intended to be a very short proposal because I'm already
a regular Git contributor, and I have an incomplete version of what I
intend to build [0].  This is not a good example of a proposal that
the Git community expects from a new student.

-- 8< -- # The project

There's another prospective student handling the SVN -> Git side of things. I want to invest time in doing the reverse: Git -> SVN conversion. There's unmerged code from back then [1] [2] to get things started. This plus svnrdump (a tool that I wrote merged into the Subversion tree) can help complete the Git -> SVN bridge and the remote helper.

# About me

I was a Summer of Code student with Git the last two summers. In 2010, I worked on a remote helper for Subversion, and in 2011, I worked on building a sequencer. Both of them are successful projects and code has been merged into upstream.

Pick me only if you're sure that I'm not getting in the way of other prospective student; I intend to work with Git this summer anyway, and I don't want the community to lose new students.

[0]: https://github.com/artagnon/git/tree/svn-fi [1]: http://thread.gmane.org/gmane.comp.version-control.git/170290 [2]: http://thread.gmane.org/gmane.comp.version-control.git/170551

Hi Ram,

Ramkumar Ramachandra wrote:

Yeah, seriously. :)

For what it's worth, if you'd like to propose a plan for getting push support in the svn remote helper to work (what the architecture would be like, what milestones would be involved along the way, and so on), then I would be happy to help flesh it out. Even forgetting about the summer of code and setting a good example, I imagine such design documents could be useful for developers and reviewers working on the project to avoid getting lost.

Thanks, Jonathan

Hi Jonathan,

Jonathan Nieder wrote:

Sure. Briefly: Give 'vcs-svn/' the ability to spit out a Subversion dumpfile. If you remember, we hit a brick wall last time when we needed a way to persist mark-referenced-blobs in the fast-import stream. Once we get svn-fi (the reverse of svn-fe) merged, the next step is in getting a reverse-branch-mapper to work. The mapper will have to sit between the repository and svn-fi, because we can't really do much with the history on the svn end.

    Ram

Ramkumar Ramachandra wrote:

Yeah.  Ok, let's start there.

If I remember correctly, before we had this idea that svn-fi would be a generic fast-import backend, so we could get support for pushing to Subversion from other version control systems like Mercurial and RCS for free. An earlier idea was to use a very minimal subset of the fast-import format. You started with a patch that taught fast-export a switch to produce that minimal subset, which was rejected because it seemed like too much of a niche use case to be worth the cost to compatibility.

However, that leaves whole swaths of the design space unexplored. For example, maybe "git fast-export" doesn't need to write the restricted format but there would be a filter that takes an arbitrary fast-import stream and converts it to the restricted thing. Or maybe it would be easiest to get something off the ground using that restricted "fast-import lite" format and only afterwards expand svn-fi to handle more commands so it can talk to the rest of the world.

In other words, if you are hitting a wall with that part which doesn't seem to have much to do with differences between git and Subversion anyway, I imagine there are easier places to start. Alternatively, if you prefer to work on making it easy for an importer to handle "ls" and "cat" commands and mark references, I think our previous attempts were misguided and we can do better. :) What do you think?

Jonathan

Jonathan Nieder wrote:

Yeah, I think the fast-export filter was a misguided attempt. In addition to git-fast-export, we have to start up a fast-import process that'll reply to our "ls" and "cat" commands, and I think we'll be good. I'm a little more worried about the mapper- I'm finding it hard to imagine a fast-import stream that contains subdirectories (branches/*) as opposed to head refs. Any idea how we'll achieve that?

    Ram

Ramkumar Ramachandra wrote:

Shouldn't it be very simple? All you need is a filter that understands the fast-import syntax and can convert

	commit refs/heads/topic
	...
	M 100644 inline "foo/bar"

to

	commit toplevel
	...
	M 100644 inline "branches/topic/foo/bar"

and

	ls topic@1 "foo/bar"

to

	ls r1 "branches/topic/foo/bar"