On 22.05.2014 16:15, Ivan Zhakov wrote:
> On 21 May 2014 14:11, Branko Čibej <brane_at_wandisco.com> wrote:
>> 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.
>>
> You are demonstrating lack of knowledge on topic discussed. The
> svn_fs_move() *does* change disk format. Could you please be so kind
> to learn code before objecting:
> subversion\libsvn_fs_fs\tree.c:copy_helper() is a good starter. Thank
> you.
Eh? Yes, you get a couple new kinds of entries in the changes list, but
the format of the list or any other on-disk structure does not change.
You don't get those new entry types if you don't use the svn_fs_move API.
>> * 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.
>>
>>
> The same problem here. Maybe I'm wrong but it seems that you do not
> fully understand the current state of the FSFS code. It so happened
> that I've found and fixed several nasty bugs in FSFSv6 and FSFSv7. And
> I'm just trying to say that we should not release FSFSv7 in the
> current state.
There will always be bugs, but that in itself is not an argument to
block a release. Can you please comment on the points I made instead of
just repeating that you've fixed some bugs?
> Anyway, you can just close issue #4502 if I'm wrong and you are
> clearly understand the code and related FSFSv7 format changes. Maybe
> I'm too conservative and care too much about the quality. Time will
> tell.
Look, nobody is ignoring your objections. I'm trying to have a
discussion about them so that we can maybe come to some agreement about
what we need to do to get FSFSv7 into a state that you would not object
to releasing it. You're apparently refusing to even have a discussion,
and that's not helpful. Telling me that I'm an idiot who can't read code
is, while possibly true, rather off-topic here.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. brane_at_wandisco.com
Received on 2014-05-22 17:15:52 CEST