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

>
>> Would cython meet the needs of increasing the speed of the python  
>> code
>> without requiring a rewrite?
>
> Actually, I've subsequently decided that this is unnecessary. Besides,
> I'm writing in C mainly for portability to msysgit (Windows). Could
> you please look at the updated version of my project proposal?
>> I work at a company with a LDAP server that I can look up the svn  
>> username to
>> get real name and email address.  This way I don't have to manually  
>> maintain a
>> svn authors file.
>
>> I'm torn on how the current system handles this,  I like all tags to
>> be tags, and
>> that if a tag had a branch like behavior (bad SVN users!), that a  
>> branch exists
>> for it, with the tag pointing to its branches head.
>
> This shouldn't be a problem to implement/ improve at the end of my
> GSoC term. However, it's important that I don't lose focus and
> concentrate on the core task at hand for GSoC, which is more about
> getting native support for SVN than anything else. I have neither the
> expertise or time (one GSoC term) to build a fantastic importer and
> get native support: I will be re-using several parts of existing
> importers for the purpose of the GSoC.
>

>> Support for SVN's blank folders.  Some of the old build systems I  
>> have used
>> need the blank folders, so I have to create to make the build  
>> work :-(
>
> Okay, this should be simple enough to implement. Thank you for  
> pointing it out.
>
>> One of my SVN repositories using the current system fails to import  
>> that
>> repository is missing a revision in its SVN history.  In other words
>> the SVN repo
>> has corrupted history the current git-svn will fail to import the  
>> repository.
>
> I'll keep this in mind when designing svn-fast-import: a certain
> revision's checkout can fail, and a mechanism to bail the user out of
> such a situation can be helpful. Again, I can't promise that this'll
> be completed by the end of the GSoC term, but I will make it easy
> enough to write the functionality in later on.
>
>> If you want me to test your work on a hairy repository with corrupt  
>> history and
>> thousands of branches, I'll do that for you.
>
> Thanks! That'll be wonderful. If my proposal gets accepted, I
> certainly will contact you (and several others) for testing, once the
> core task of the GSoC is complete.
>
>> But working at a company with lots of history in SVN makes me  
>> passionate
>> about the SVN integration in git :-)
>
> Good to know. Thank you for your support :)
>
> -- Ram