[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1483186 - in /subversion/branches/1.8.x: ./ STATUS subversion/libsvn_client/repos_diff.c subversion/tests/cmdline/diff_tests.py

From: Ivan Zhakov <ivan_at_visualsvn.com>
Date: Mon, 20 May 2013 18:05:29 +0400

On Mon, May 20, 2013 at 5:59 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 05/20/2013 08:45 AM, Ivan Zhakov wrote:
>> On Mon, May 20, 2013 at 4:35 PM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>>> This bug fix is a single boolean toggle that affects one type of operation
>>> (a repository diff which adds empty files) through effectively a single
>>> codepath. The bug is well understood; the fix extremely localized. There's
>>> no need to restart the soak period for this.
>>>
>> Sometimes single boolean toggle may affect a lot of code flow.
>> In this case the fix made in one of inner functions: diff algorithm. Which
>> is used in many places: merges and diffing.
>
> You've got your layering wrong on this one, Ivan. The code fixed by this
> change is used by repository diffs, which sits *atop* the lower-level diff
> display generation and merge handling logic.
>
> As I've already explained, this bug is triggered by one scenario: a
> repository diff which adds empty files. I'll grant you that sometimes that
> diff is shown to us on the console and sometimes it's merged into the
> working copy. But it's a single, well-understood scenario that's failing
> here, and the fix makes precisely that change needed to fix it (by reverting
> to the previous behavior of ensuring that the tempfile gets opened and
> closed rather than merely skipped). The fix is not widespread. It's not
> far-reaching. We didn't blaze any new trails here. In summary: this is not
> a destabilizing change.
>
I just noted that this fix also fix crash of merging addition of empty
file. Which very often case without workaround. So fix is critical,
because we use repos diff in our merge code.

>>> We also have a one-week soak period extension as part of our policy:
>>> because this is a critical bugfix, *if* we were currently in our final week
>>> of soak time, we would need to re-roll a new RC with the fix and extend our
>>> soak time by another week.
>>>
>> I'm fine to extend soak period because of this change instead of full
>> restart, but we need some kind of soak period extension.
>
> Please read our policy. The docs pretty clear:
> http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization
>
I read it many times, Mike :)

-- 
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2013-05-20 16:06:22 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.