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.
--
Eric Wong
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html