Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eric Wong <normalperson@xxxxxxxx> writes: > > >> 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? > > > > It's not common at all. Some broken Windows clients were able to > > create it. > > > >> 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? > > > > Previously, git-svn would just stop importing and refuse to continue. > > So allowing the user to enable it would be a problem; too. I don't > > recall the error being easy to distinguish from other errors. > > > >> 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. > > > > I'm considering disabling it by default, too. > > I leave it entirely up to you to choose whichever default you find > sensible (I do not think I have to say this). I wasn't complaining your > original choice to stay on the safer side, with an option to trigger a > faster but potentially riskier behaviour. > > I was curious how black-and-white the deciding factor for a sensible > default would be for this particular case. If there are no objections by the time I get home tonight I'll disable the workaround by default. -- 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
