Eric Wong <normalperson@yhbt.net> writes:

quoted text
>> 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.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html