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

Re: Moving towards a 1.9.x branch

From: Branko Čibej <brane_at_wandisco.com>
Date: Wed, 21 May 2014 12:11:40 +0200

On 20.05.2014 16:19, Ivan Zhakov wrote:
> On 16 May 2014 21:27, Ben Reser <ben_at_reser.org> wrote:
> [....]
>
>> To that end I'd like to branch no later than June 13th. Please figure out what
>> blockers you have on a 1.9.0 release and have them appropriately flagged in the
>> issue tracker by May 23rd. I'd like to see us having a decision on what we're
>> going to do with those issues by June 6th. Then we can finish up with those
>> issues (or be well on the way towards it) by June 13th.
>>
> Hi Ben
>
> I've filled the following issues per your request:
> * Issue #4501 "Remove svn_fs_move() API"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4501

Why? It's an experimental API, and as such, doesn't prevent us from
completely removing it or changing it at any time. Also, as far as I'm
aware, it doesn't imply any changes in the storage layer.

> * Issue #4502 "Remove FSFS7 disk format changes"
> http://subversion.tigris.org/issues/show_bug.cgi?id=4502

Let's take your arguments one at a time:

  * 1. and 2. essentially say that bugs in new FSFS code can cause data
    corruption. True ... but this is true of /any/ change we make in
    the code. If we take this argument at face value, we may as well
    revert back to FSFSv1 to reduce the risks. I hope you'll agree that
    doesn't make any sense. What you need to do here is provide a
    plausible argument that the performance and storage improvements
    brought by FSFSv7 do not outweigh the increased risk of corruption.

  * You have a point about 3, but it's not an argument for removing
    FSFSv7 code; it's an argument for putting some effort into expanding
    the test suite. On that note, I have to ask: what have YOU done to
    make this happen, apart from telling others to write more tests? Do
    you have any specific suggestions for the kind of tests that would
    satisfy you? Note that FSFSv7 is no different in this respect than
    any other FSFS improvement in the past; so, for example, the lack of
    cross-version regression tests could be construed as an argument for
    blocking 1.9 even if FSFSv7 did not exist.

  * 4. is just another way of saying 1., 2., and 3.; all the comments
    above apply.

  * Your last point is, so sorry, just nonsense. It doesn't matter where
    some particular code was first written; the fact that logical
    addressing was extracted from FSX has no bearing whatsoever on the
    code quality, or on releasing FSFSv7. There is no code duplication
    in FSFS; on the contrary, the code duplication is in FSX, which is
    experimental and could change completely at some point; it's simply
    irrelevant to this discussion.

-- Brane

-- 
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-05-21 12:12:23 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.