From patchwork Fri Jul 21 16:26:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Vetter X-Patchwork-Id: 9857273 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 77CB160388 for ; Fri, 21 Jul 2017 16:26:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 63B002871C for ; Fri, 21 Jul 2017 16:26:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 5899228765; Fri, 21 Jul 2017 16:26:39 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 6545D2871C for ; Fri, 21 Jul 2017 16:26:38 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 1D28C6E045; Fri, 21 Jul 2017 16:26:36 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) by gabe.freedesktop.org (Postfix) with ESMTPS id 351CD6E045 for ; Fri, 21 Jul 2017 16:26:34 +0000 (UTC) Received: by mail-wm0-x231.google.com with SMTP id e131so18404250wme.0 for ; Fri, 21 Jul 2017 09:26:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=from:to:cc:subject:date:message-id; bh=zUXf76K2VKKX77z2vEBPF7Yi682pGI6egS30qQ074uk=; b=gMCqVqcdZy3j24CNqlkNx9aiHaapslvllqWBslQ/qmr7SsKE3/kxN4Nt9rREs1c8s5 p+PkePTXoMTXozJLPSjsQN8KqROXVxB6YCzV/l4JjIawGdMg/6JqI+Uca3OKPJUQd7NN wUq21/D30gZK5/rgbHzfkuT8Jb46mIOkQXehw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=zUXf76K2VKKX77z2vEBPF7Yi682pGI6egS30qQ074uk=; b=UvEwOKuG9txFC5k41g1l6//RF4jP0D5/JeQkMRNTFN/Vmz1z9Bf/Makp1ksINb2oHa 51RVntvtQ+Jq7zD1yX6q8/G14R7oefbElWLdfs5HpvZq75UUY8zXzXIuKJLTLVP2zDFb gp1gb5hHAepxg9h2Am5fUZ7KMS+10M7uLZEkL4pa86hR+8VnleywC66KOakVzUCfIKIt iy+Ip47Ij7+EKAtqwRgIGpl+pWSYroYjC1eyKHg4CZHSTiVvRd9kuKdVe/wa7qAcy6fh M7vGLoqF30VPZN7mbLaRnHgzM+YGC4MWJqcg/vKxsw6QqmnL9UaXOFpP6w64JFiKZV1Z paEw== X-Gm-Message-State: AIVw111cn1CbOhuHZzi+IVvicZM8YFwSNgPINl6m2+tQUPGWGgEE5MeK K2KrpsNt9r+nx7hcRpo= X-Received: by 10.80.219.203 with SMTP id s11mr5255947edk.113.1500654392502; Fri, 21 Jul 2017 09:26:32 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:5640:0:960b:2678:e223:c1c6]) by smtp.gmail.com with ESMTPSA id d36sm3160636edb.63.2017.07.21.09.26.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Jul 2017 09:26:31 -0700 (PDT) From: Daniel Vetter To: DRI Development Subject: [PATCH] dim: Make rr-cache more robust Date: Fri, 21 Jul 2017 18:26:27 +0200 Message-Id: <20170721162627.23304-1-daniel.vetter@ffwll.ch> X-Mailer: git-send-email 2.13.3 Cc: Daniel Vetter , Daniel Vetter X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP There's a failure mode I didn't take into account: 1. You start a dim rebuild-tip, and update your rr-cache. Because you didn't push for a while, this adds some really old files (but with today's timestamp). 2. 2nd person finished their dim rebuild-tip and garbage-collects the old rr-cache entries. 3. We get to commit_rr_cache, and the first thing the script does is update the rr-cache branch, which deletes the old entries. 4. Then we copy them over again, because their timestamp is fresh. 5. The filtering doesn't catch them, because git ls-files doesn't list them (they're deleted files after all). 6. They get re-added right away. I think this is what happend today between Chris and Imre, and resulted in a bit of confusion. I think if we pull only after copying this would be avoided, since the pull would delete the files the 2nd person gc'ed in step 2, and so prevents them from getting re-added. Worst case there's a functional conflict and the pusher needs to clean up the mess. Signed-off-by: Daniel Vetter --- dim | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/dim b/dim index de3264aa0f76..53771762f15d 100755 --- a/dim +++ b/dim @@ -512,9 +512,9 @@ function commit_rerere_cache if git_is_current_branch rerere-cache ; then remote=$(branch_to_remote rerere-cache) - git pull >& /dev/null rm $(rr_cache_dir)/rr-cache -Rf &> /dev/null || true cp $(rr_cache_dir)/* rr-cache -r --preserve=timestamps + git pull >& /dev/null git add ./*.patch >& /dev/null || true for file in $(find rr-cache/); do if ! git log --since="60 days ago" --name-only -- $file | grep $file &> /dev/null; then