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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html