From: Junio C Hamano Date: Mon, 02 Feb 2009 03:03:47 GMT Subject: Re: [PATCH] git-svn: allow disabling expensive broken symlink checks Message-ID: <7vbptlo7zg.fsf@gitster.siamese.dyndns.org> In-Reply-To: <20090201021844.GB18855@dcvr.yhbt.net> Eric Wong 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 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.