Eric Wong <normalperson@xxxxxxxx> writes: > Since dbc6c74d0858d77e61e092a48d467e725211f8e9, git-svn has had > an expensive check for broken symlinks that exist in some > repositories. This leads to a heavy performance hit on > repositories with many empty blobs that are not supposed to be > symlinks. > > The workaround is enabled by default; and may be disabled via: > > git config svn.brokenSymlinkWorkaround false > > Reported by Markus Heidelberg. > > Signed-off-by: Eric Wong <normalperson@xxxxxxxx> How common is this breakage in people's subversion repositories that dbc6c74d (git-svn: handle empty files marked as symlinks in SVN, 2009-01-11) works around? What's the way to recover from a broken import, when the subversion repository does have such a breakage, and the user used git-svn that predates dbc6c74? Is it very involved, and it is much better to have the safety by default than to force everybody else who interacts with non-broken subversion repository suffer from this performance penalty? Because the fix (that is broken from the performance angle) is relatively recent, I am wondering if it makes more sense to turn it off by default, and allow people with such a broken history to optionally turn it on. -- 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
