Adam Spiers <git@xxxxxxxxxxxxxx> wrote: > Mail-Followup-To: git mailing list <git@xxxxxxxxxxxxxxx> Hi Adam, MFT is frowned upon here. > Something is badly wrong here ... > > $ cd $svn_wd > $ time svn propget -R svn:ignore >/dev/null > svn propget -R svn:ignore > /dev/null 0.28s user 0.20s system 98% cpu 0.490 total > $ cd $git_wd > $ time git svn show-ignore > show-ignore.out > git svn show-ignore > show-ignore.out 20.52s user 33.69s system 1% cpu 1:23:42.17 total > > That's 10,000 times slower for what is effectively the same source > tree! Admittedly the svn propget was a "warm" run and took longer the > first time around, but even so there are several orders of magnitude > difference. It's the difference between reading locally vs remotely. git svn always looks at the remote repository for this information. In your example, svn was looking at the working copy where it already has that information in an easily accessible form. Try running svn against your repository URL instead for a comparison: time svn propget -R svn:ignore $SVN_URL >/dev/null > I had a quick look at the code and it seemed to be doing the svn tree > recursion itself via Git::SVN::prop_walk(), which might explain why. > However I did not have time to dig deeper, so would welcome any ideas. It would be possible to reconstruct the information given untouched copies of unhandled.log inside $GIT_DIR/svn/**. On the other hand, it does require running through the history of the project and I don't think it's worth it for an operation that should be rarely needed. I designed the output of "git svn show-ignore" be stored in $GIT_DIR/info/exclude -- 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