From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f65.google.com (mail-lf1-f65.google.com [209.85.167.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 4C22E469719 for ; Fri, 20 Mar 2020 20:45:16 +0300 (MSK) Received: by mail-lf1-f65.google.com with SMTP id j188so1386815lfj.11 for ; Fri, 20 Mar 2020 10:45:16 -0700 (PDT) Date: Fri, 20 Mar 2020 20:45:14 +0300 From: Konstantin Osipov Message-ID: <20200320174514.GB5670@atlas> References: <59ece61283f53c6d2772b81ffc8a783873ef4b0b.1584703666.git.korablev@tarantool.org> <20200320133333.GB29536@atlas> <20200320150639.GC14930@tarantool.org> <20200320151936.6fmr5jkrkeqxwenc@tarantool.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200320151936.6fmr5jkrkeqxwenc@tarantool.org> Subject: Re: [Tarantool-patches] [PATCH] vinyl: update mem ptr in vy_build_insert_tuple() after yield List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kirill Yukhin Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org * Kirill Yukhin [20/03/20 18:23]: > It was mentioned multiple times, that we're using separate > files for bug fixes (and will go further in future). This works for gcc where each problem is usually a standalone compilation unit, and once a compiler has run, it leaves no memory/no state. It's as terrible idea for a database, when one test case may impact another, so putting test cases together has a sum effect. Not to mention the speed of set up and tear down. To sum up: yet another arrogant and arbitrary decision done without due process. In any case, my comment was not just about that. It was about a yet another push without a proper second code review and neglecting the previous reviewer's comments. -- Konstantin Osipov, Moscow, Russia