[GSoC] Git to SVN bridge

[GSoC] Git to SVN bridge

[Ramkumar Ramachandra]

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

Re: [GSoC] Git to SVN bridge

[Jonathan Nieder]

Hi Ram,

Ramkumar Ramachandra wrote:

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

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

Re: [GSoC] Git to SVN bridge

[Ramkumar Ramachandra]

Hi Jonathan,

Jonathan Nieder wrote:
> 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.

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

Re: [GSoC] Git to SVN bridge

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

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

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

Re: [GSoC] Git to SVN bridge

[Ramkumar Ramachandra]

Jonathan Nieder wrote:
> 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?

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

Re: [GSoC] Git to SVN bridge

[Jonathan Nieder]

Ramkumar Ramachandra wrote:

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

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"