From: Eric Wong <normalperson@yhbt.net>
Date: Tue, 03 Feb 2009 19:10:21 GMT
Subject: Re: [PATCH] git-svn: allow disabling expensive broken symlink checks
Message-ID: <20090203191021.GB2077@dcvr.yhbt.net>
In-Reply-To: <7v4ozcdnbt.fsf@gitster.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> 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