git-svn todo/wishlist

[Eric Wong <normalperson@yhbt.net>]

There are several things I'd like to see in git-svn, but haven't had
much time to do myself, and more interesting things keep popping up :)

Some of these I dread working on because it involves having to wrangle
with the (imho) overly complex SVN API, but the end user experience
should be better afterwards :)

1. Ability to transfer deltas over fetches.  Currently, we transfer
   deltas only when committing, but when we fetch, we fetch whole files
   if they're modified (like git with dumb protocols).  Our current method
   is very fast with fast connections and the code is very simple (I
   ripped the code off svnimport :), but users behind slower links will
   find the waiting for the svn server to generate a delta to be faster.

2. Ability to login and accept SSL certificates without relying on
   the caching done by the svn command-line client.  I tried doing this
   a while back, but was unsuccessful, and didn't look into it further.
   I couldn't get svm/SVN::Mirror to work with this, either.  This could
   be a bug in SVN bindings, too...

3. Documentation.  The -i/GIT_SVN_ID= stuff should probably be promoted
   more now that branches/tags are better supported.  More examples,
   too...

4. Would storing the SVN URLs in .git/config be a good idea?  I'm
   considering it as it would potentially simplify some things for
   people tracking multiple trees.

5. Ability to create tags/branches on the SVN side.  I'd like to avoid
   having to re-fetch all the new stuff into git if I created a new
   tag/branch on the SVN side.  This shouldn't be very hard to do.
   Avoiding re-fetching new stuff when somebody else creates a
   tag/branch would also be nice, but more involved.

6. Faster multi-fetch across a single repository.  This would probably
   be easier if we relied less on global variables and subprocesses.

7. Some method of handling svn:externals would be a nice feature to
   have.  This would be easier with subproject support from git.

8. Packed refs.  I haven't looked into this at all yet, I just heard of
   it just heard about it a while back and it ("packed refs") sounded
   like it could replace the .rev_db files I'm using in git-svn.

9. If not packed refs, then .rev_db could be transparently compressed.
   It's good for high-activity trunks; but very space-inefficient
   for tags and sparse branches.

--