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.
>
> * 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.
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.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Received on 2014-05-22 17:10:05 CEST