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

From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Mar 27, 2010, 06:46 UTC
Message-ID: <f3271551003262346g286e7e72u751e15cbc99a9c1@mail.gmail.com>
In-Reply-To: <3d4937ff1003262240t6159d9c5sc9253f555c3aed1@mail.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