Re: native-git-svn: A Summer of Code 2010 proposal

[Ramkumar Ramachandra <artagnon@gmail.com>]

Hi,

I just prepared another revision of my proposal- I've tried to be
clearer about the objective, and included a timeline this time. Note
that I've also changed the name from native-git-svn to git-remote-svn,
as recommended by Sverre.

======================================
Project Proposal: git-remote-svn | Native SVN support in Git

== The Outline ==
The objective of git-remote-svn is to allow native interaction with
SVN repositories in Git. The motivation for writing this comes from
the shortcomings of the current approach: git-svn.
1. It is essentially an arcane 5000-line Perl script that doesn't use
git-fast-import/ git-fast-export. It converts an SVN repository to a
Git repository by hand. This makes it virtually unmaintainable.
2. The UI is unnatural and complex. git-svn-* has some commands
corresponding to git-* commands, and it can be quite difficult for the
user to understand which one to use in different situations.
3. It handles the standard trunk/branches/tags layout well, but it
doesn't know how to handle non-standard/ changing SVN layout.
4. There's an array of other annoyances which makes it quite
imperfect. For example, it ignores all SVN properties except
svn:executable.

While the last two problems can be tackled in git-svn.perl itself, a
fresh approach is required to tackle the first two. git-remote-svn is
a proposal for an alternative approach.
1. Several good SVN exporters already exist, and using them with
git-fast-import should simplify a lot of the plumbing git-svn tackles
by hand.
2. Using a remote helper to keep track of SVN remotes will simplify
the UI greatly. The fresh UI will allow for a simple `git clone
svn://example.com/myrepo` and multiple subsequent `git pull`
invocations.

However, the project does not aim to be compatible with git-svn, and
does not serve as an immediate replacement. It can be considered fully
successful after the functionality described in all the components
have been written. Merging the project to upstream will involve small
changes to the Git codebase to incorporate the native UI. I
additionally hope that this project will serve as a roadmap for other
projects that involve natively supporting other versioning systems in
Git.

== The Technicalities ==
I've discussed the project with Sverre Rabbelier at length over email.
The plan is to build component-wise. The distinct components are:
1. An SVN client that uses libsvn to fetch/ push revisions to a remote
SVN repository.
2. An exporter for SVN repositories, which will extract all the
relevant revision history and metadata to import into Git.
3. A remote helper for Git that takes the data from this SVN exporter,
and uses git-fast-import to create corresponding commits in Git.
4. Another remote helper to export commit data and metadata from Git
to import into SVN.
5. An importer for SVN, which will create revisions in SVN
corresponding to commits in Git.
6. A UI that glues all the components together.

Due to a licensing conflict, the details of which can be found here
[1], git-remote-svn will link to libsvn, but will NOT link to Git. It
will simply use a thin wrapper to call compiled Git executables
(referred to as remote helper in article). The following resources
will help build the various components:
1. git_remote_helpers/git/git.py is a small remote helper written by
Sverre that wraps around git-fast-import. I plan to extend this to
wrap around git-fast-export as well.
2. git-svn.perl contains a two-way mapping, parts of which I plan to implement.
3. Thiago Macieira's svn-all-fast-export [2] has a complete SVN -> Git
mapping. I plan to take several ideas from the branch/ tag mapper in
repository.cpp.

== Timeline ==
April 26 - May 24: Study svn-all-fast-export extensively, and chalk
out a mapper for SVN branches and tags. Take time to become
comfortable with libsvn.
May 24 - June 10: Write a minimal importer/ exporter for SVN in
Python. It should allow interconversion between commit messages,
timestamps, authors corresponding to each revision/ commit. Also
figure out how to preserve the data in SVN properties.
June 10 - June 25: Extend the the remote helper in
git_remote_helpers/git/git.py to do git-fast-export as well. Make the
importer/ exporter for SVN work with it.
June 25 - July 5: Implement a minimal SVN client, and make it work
with the SVN exporter.
July 5 - July 10: Write a quick UI binder. This will involve
modifications to builtin-push, builtin-fetch, builtin-clone, and
remote to use the SVN client to perform the corresponding actions in
the case of an SVN remote.
July 10 - July 16: Scrub code and write documentation for mid-term
evaluations. Commit changes to the remote helper to upstream. Try to
get the other changes into `next`.
July 17 - August 9: Implement the branch and tag mapper.
August 9 - August 16: Write more documentation and get everything
ready for final evaluations. Commit the SVN importer/ exporter and UI
changes.

== Who am I? ==
I'm Ramkumar, a student at the Indian Institute of Technology,
Kharagpur. I haven't contributed more than a few small patches to Git
[3], and I look at this project as a fantastic opportunity to get more
involved with the community. In the summer and winter of 2008, I
worked with a Django-based startup. The team comprised of three
experienced Python developers, one designer to steer the project, and
an undergraduate student- me. We versioned everything on Git, deployed
on Apache/ PostgreSQL, using Amazon S3 for static content. While
working for the startup, I also contributed to South.

C, C++ [4], and Python are my strongest languages. I've additionally
learnt Common Lisp through an Emacs Lisp I wrote in summer 2009 [5].
I'm known to be very communicative, both in person, and over email/
chat. The style and clarity of my communication is seen in the slides
I used at FOSS.IN/2009 in winter 2009 [6].

== Notes ==
[1] http://thread.gmane.org/gmane.comp.version-control.git/139545
[2] git://repo.or.cz/svn-all-fast-export.git
[3] 52eb5173ac and 88d50e78c3
[4] On a related note, I've also contributed a little to Chromium
[5] http://github.com/artagnon/ublog.el
[6] http://artagnon.com/wp-content/uploads/haskell-internals.pdf and
http://artagnon.com/wp-content/uploads/unladen-swallow.pdf
======================================

Again, I'd really appreciate comments.

Thanks,
Ramkumar