Hi, It looks like I've hit a wall with the dumping functionality in svnrdump- it's merged in cleanly with tests to show where it passes along with others that highlight the places that it fails. We've determined that it cannot do better until the underlying infrastructure (RA layer) is improved, so I've finally stopped working on this. The dumpfile that it produces is completely valid, but doesn't match exactly with the dumpfile that `svnadmin dump` produces. Since Junio has recommended that I don't get svnrdump merged into git.git, I'll maintain an out-of-tree version that compiles against Subversion 1.6; however, git-remote-svn will have to spawn the executable instead of just including a header and using the API that it exposes atleast until the next Subversion release. With my subcommand patch merged in, I've removed my svnrload branch and started working on the "load" subcommand directly in trunk. The functionality I expect to implement is "svnrdump load" -- it'll read a dumpfile from stdin and commit the revisions that it represents to a specified remote repository. Unfortunately, this is quite non-trivial, and I'm working *really* hard to try and finish this before the end of the SoC term. I've found a tool called svnmucc in the trunk that I can use as reference while writing this. svn-fe itself is in excellent shape in `pu` (thanks to Jonathan's extensive cleanup and re-roll it while I was flying halfway across the world) . I expect that it'll make it all the way to `master` without any issues. Although I've finished implementing an svndiff0 parser, I'm having trouble integrating it into svn-fe; I'm currently attempting to refactor the line_buffer library in svn-fe to load the diff into memory all at once so that I can apply it. I've determined that unless someone else helps out, I might not be able to finish this within the timeline of the SoC (related: my email earlier this week calling for manpower) and get it merged. To make svn-fe filesystem-aware, a LOT of refactoring is required. In short, when a blob is required, it should issue an `M 040000 <SHA1>` to `git-fast-import` (see 334fba656b50 in `pu`) to fetch the right tree object when an SVN copyfrom is seen. To be able to do this however, it has to know the SHA1 of all the commits that it passes to git-fast-import: this information must come from git-fast-import. It needs another patch to print the SHA1 of the commit objects everytime it finishes writing a commit. Related to this, there's a discussion about how loose objects in the Git store aren't inaccessible by callers (and how cat-file can be used in fast-import?). Again, I will personally not be able to handle this in the SoC term. -- Ram -- 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