Re: GSoC proposal for svn remote helper

[Dmitry Ivankov <divanorama@gmail.com>]

resending in plain-text to make vger.kernel.org happy.

Hi.

This is the second iteration of my GSoC proposal, the first one was on
melange and
got nice responses from Jonathan Nieder, David Barr and Sverre Rabbelier.
However the conclusion was that it looks too ambitious, and that I should roll
out it to the list. So here it is in a diff-style.

I would like to work on "Remote helper for Subversion and git-svn".
My major motivation is to make git-svn repository easy to clone, and to make
git-svn (fetch) faster on huge repositories.

Project Goals:
+ * Design and create fully functional prototype of new git-svn which is
cloneable and quite fast. By fully functional I mean that it'll be
able to fetch, push, etc. but probably won't have automatic tags and
branches discovery and like, but will allow it to be implemented on
top. Oh, it just hit me that given a path (read trunk) to track and a
svndump it looks trivial to discover all it's branches - just seek for
copies.
+ * Get all the needed core git changes merged. Some of these exist already and
only need help with polishing, reviewing and merging.
- * Complete git-remote-svn and get it merged.
- * Implement new git-svn and get it merged too.
+ * Make the prototype as close to being merged as possible.

Milestones for prototype functionality:
 * Be able to track whole / as the only remote branch.
 - * Be able to dumb track some path as the only remote branch. Could be done
 either via pruning in git-remote-svn or via maintaining custom branch,
 probably with the help of git-filter-branch.
 - * Finally, be able to work with multiple svn branches. There are many ways to
 achieve this and several kinds of what features the ability to work includes,
 so there even should be a milestone for choosing the ones to implement.
 + * Be able to track several "paths" as branches so that they have expected
 history (whole path copying is branching), and so that these branches are
 cloneable (will be the same in different git-svn repositories tracking the
 same svn repo, under reasonable assumptions like svn:author not being
 propedited :) ).
 * Anything else that'll appear to be interesting and related.

 Sorry for the late submission to this list, I was really puzzled on how to
 make my proposal more realistic and still as useful for git-svn as possible.