Hi, > Oh, from that point of view the svn mirror is a bystander. I was developing these tools at the same time as svnrdump (or at least prior to a stable version of svnrdump). So when I found that running "svnadmin dump | svn-fe | git fast-import" on the server was taxing the system, I decided it was better to create a dump file, copy it to my local machine, and run svn-fe and fast-import locally. Once I had the dump file, the local mirror sped up the SVN::Ra calls in buildSVNTree, and made any "did that really happen in svn?!" questions a little easier to answer. So, I think there's two valuable nuggets per commit omitted at the moment in svn-fe. Firstly, the longest common root between all paths in the commit, which can be computed efficiently. Secondly, the copyfrom_rev and copyfrom_path for the copy operation that targets the common root. The second nugget can be noted while computing the first. >From my reading of buildSVNTree.pl, these two nuggets drive the mapping logic. The first nugget can be computed in git-land fairly easily. The second requires information not embedded in the git commit graph. I suggest that svn-fe be extended to annotate the commits with this information. Implementation-wise, the revision context should be extended to include: * longest common path * source revision of copy operation targeting longest common path * source path of copy operation targeting longest common path -- David Barr-- 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