{"thread":{"id":"21407","subject":"git svn show-ignore is excrutiatingly slow","startedAt":"2009-10-28T17:43:07Z","lastAt":"2009-10-30T06:39:36Z","messageCount":2,"participants":["Adam Spiers","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"126170","messageId":"20091028174307.GA5691@atlantic.linksys.moosehall","threadId":"21407","inReplyTo":null,"subject":"git svn show-ignore is excrutiatingly slow","fromName":"Adam Spiers","fromEmail":"git@adamspiers.org","sentAt":"2009-10-28T17:43:07Z","receivedAt":"2009-10-28T17:43:07Z","isPatch":false,"sender":{"key":"git@adamspiers.org","avatar":"https://avatars.githubusercontent.com/u/100738?v=4"},"body":"Something is badly wrong here ...\n\n$ cd $svn_wd\n$ time svn propget -R svn:ignore >/dev/null\nsvn propget -R svn:ignore > /dev/null  0.28s user 0.20s system 98% cpu 0.490 total\n$ cd $git_wd\n$ time git svn show-ignore > show-ignore.out\ngit svn show-ignore > show-ignore.out  20.52s user 33.69s system 1% cpu 1:23:42.17 total\n\nThat's 10,000 times slower for what is effectively the same source\ntree!  Admittedly the svn propget was a \"warm\" run and took longer the\nfirst time around, but even so there are several orders of magnitude\ndifference.\n\nI had a quick look at the code and it seemed to be doing the svn tree\nrecursion itself via Git::SVN::prop_walk(), which might explain why.\nHowever I did not have time to dig deeper, so would welcome any ideas.\n\nThanks,\nAdam\n"},{"id":"126354","messageId":"20091030063936.GA13527@dcvr.yhbt.net","threadId":"21407","inReplyTo":"20091028174307.GA5691@atlantic.linksys.moosehall","subject":"Re: git svn show-ignore is excrutiatingly slow","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2009-10-30T06:39:36Z","receivedAt":"2009-10-30T06:39:36Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Adam Spiers <git@adamspiers.org> wrote:\n> Mail-Followup-To: git mailing list <git@vger.kernel.org>\n\nHi Adam, MFT is frowned upon here.\n\n> Something is badly wrong here ...\n> \n> $ cd $svn_wd\n> $ time svn propget -R svn:ignore >/dev/null\n> svn propget -R svn:ignore > /dev/null  0.28s user 0.20s system 98% cpu 0.490 total\n> $ cd $git_wd\n> $ time git svn show-ignore > show-ignore.out\n> git svn show-ignore > show-ignore.out  20.52s user 33.69s system 1% cpu 1:23:42.17 total\n> \n> That's 10,000 times slower for what is effectively the same source\n> tree!  Admittedly the svn propget was a \"warm\" run and took longer the\n> first time around, but even so there are several orders of magnitude\n> difference.\n\nIt's the difference between reading locally vs remotely.  git svn always\nlooks at the remote repository for this information.  In your example,\nsvn was looking at the working copy where it already has that\ninformation in an easily accessible form.\n\nTry running svn against your repository URL instead for a comparison:\n\n  time svn propget -R svn:ignore $SVN_URL >/dev/null\n\n> I had a quick look at the code and it seemed to be doing the svn tree\n> recursion itself via Git::SVN::prop_walk(), which might explain why.\n> However I did not have time to dig deeper, so would welcome any ideas.\n\nIt would be possible to reconstruct the information given untouched\ncopies of unhandled.log inside $GIT_DIR/svn/**.  On the other hand, it\ndoes require running through the history of the project and I don't\nthink it's worth it for an operation that should be rarely needed.  I\ndesigned the output of \"git svn show-ignore\" be stored in\n$GIT_DIR/info/exclude\n\n-- \nEric Wong\n"}]}