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

[Steven Michalske <smichalske@gmail.com>]

Ramkumar Ramachandra <artagnon <at> gmail.com> writes:
---8<------
> The following resources are relevant to the project:
> 1. git_remote_helpers/git/git.py is a minimalistic remote helper
> written by Sverre. I plan to extend this as much as possible before
> rewriting it in C.

Would cython meet the needs of increasing the speed of the python code
without requiring a rewrite?

> 2. libsvn contains excellent documentation and clear examples to
> create the SVN client.
> 3. git-svn.perl has a lot functionality that I plan to re-implement in
> native-git-svn:
>    3.1 parse_svn_date: Given a date (in UTC) from Subversion, return a
> string in the format "<TZ Offset> <local date/time>" that Git will use
>    3.2 load_authors: <svn username> = real-name <email address>
> mapping based on git-svnimport

One feature that I would like to see is a way to call an application for a name
lookup author file maintenance.

i.e. if the SVN authors file is missing the lookup,  call the lookup tool.

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.

This is really a remote helper component, not just SVN

>    3.3 do_git_init_db: Create and maintain svn-remotes
>    3.4 get_commit_entry: Parse commit messages, and encode them; SVN
> requires messages to be UTF-8 when entering the repo
>    3.5 cmd_branch: Handle branching/ tagging

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.

>    3.6 cmd_create_ignore: Reads svn:ignore and puts the information
> into .gitignore
> 4. There are several existing third-party SVN exporters worth looking into [2].
-----8<------

A couple of side thoughts.

--
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 :-(
can't use
git-bisect easily.  Well it's that i have to make the bisect run
script make the
needed folders, not too hard, but annoying.  Could we track if in a particular
SVN revision we had a blank folder that was either created or removed.  Stuff a
hidden file '.git_svn_empty_folder' or a .gitignore with a * in it so
git can then
track the SVN's empty folder, and if the SVN folder gets contents the
.git_ignore
needs the ignore removed?

--
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.

Example:  R31 of the SVN repo is this status, R32 fails to checkout
due to a SVN
error, but R33 will checkout and is valid.  I would like to see the
helper pause
and ask me what to do.  Either fail or skip that revision.  It's a
shame the history
is gone, but I now have to tell the current git-svn to do a shallow clone and
start at R33 and I loose all of commits R1 to R31, This leads to branches that
have no known roots......  My case is this happened roughly at
revision 1700, the
server's hard drive crashed and restore was done with a backup that was at a
revision around 1500 so there is a big gap..... of lost history, but
that history is
5-6 years old so the daily backups to reconstruct it are LONG gone.
Too bad we didn't have git back then, could have restored all the
history with a
push! ;-)

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.


--
In that same corrupt repository, each branch has a large PDF that NEVER
changes.  This makes me think that it might make exports faster if I could tell
the SVN client that a file is static, and to only track if it gets
removed or size
changes,  don't know if libsvn would let you do that....  You might
even be able
to detect that kind of condition, large unchanging binary like files,
 might make a great bandwidth/speed optimization.



Sorry if I didn't see these points brought up in other emails on your
proposal.
But working at a company with lots of history in SVN makes me passionate
about the SVN integration in git :-)


Good luck!
Steve