Hi, On Fri, 12 Feb 2010, Eric Wong wrote: > Sverre Rabbelier <srabbelier@xxxxxxxxx> wrote: > > Heya, > > > > Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a > > bit sad at the moment (only two idea's). Part of the reason Git was > > listed as 'example application' before was our awesome idea list, we > > should live up to that again this year :). If you feel like mentoring > > a summer of code student, or if you have a great idea, please add it > > to the list so that our would-be students have some variety in > > choosing their projects. I just added "A remote helper for svn" [1] > > myself, since I would love to see native svn support in git. Would > > either Daniel or Eric (or someone else of course) be interested in > > being a co- or backup-mentor for this project? > > Hi Sverre, > > I can't commit to anything, but they're welcome to email me/the list for > guidance. I've left some notes further down in this email as well... > > It's been a long time since I've had time (or need, since most projects > I care about have moved to git) to hack on git-svn. > > The git-vcs-* stuff is interesting and a good reason to refactor/redo > parts of git-svn to work with it. It's been overdue for a > refactoring/cleanup for _years_ now. > > > I can't say SVN (nor the Perl support libraries) are pleasant to work > with. Things to keep in mind: > > * avoid memory leaks by using explicit pools > > * avoid memory errors (which are much harder to track down > wrapped around layers of SWIG/XS/SVN library abstractions). > We sometimes copy SVN native data types into normal Perl ones > ASAP to avoid errors/leaks > > * inconsistent between different repo types: > - escaping may be rules are stricter/laxer for some paths > - error codes aren't consistent > > * inability to safely maintain multiple connections to a repo > in one process > > I'm sure I'm missing some things here that my mind just blocked > out entirely... > > All of them should be well-documented in the git-svn commit history > and/or comments. Would it not make sense to implement git-remote-svn as a C program? That should help matters especially on Windows, where git-svn is very slow due to its using MSys (which is a stripped-down Cygwin, as you know, jumping through hoops to bring some POSIX-iness to Windows). Ciao, Dscho -- 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