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

[Ramkumar Ramachandra <artagnon@gmail.com>]

[Please don't cull people from cc]

> 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