On 22.05.2014 16:15, Ivan Zhakov wrote: > On 21 May 2014 14:11, Branko Čibej <br...@wandisco.com> wrote: >> On 20.05.2014 16:19, Ivan Zhakov wrote: >> >> On 16 May 2014 21:27, Ben Reser <b...@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. br...@wandisco.com
