From users-return-26896-archive-asf-public=cust-asf.ponee.io@subversion.apache.org Fri Mar 2 04:25:21 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8D48D18064D for ; Fri, 2 Mar 2018 04:25:20 +0100 (CET) Received: (qmail 46961 invoked by uid 500); 2 Mar 2018 03:25:18 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 46941 invoked by uid 99); 2 Mar 2018 03:25:17 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Mar 2018 03:25:17 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 52CBCC1BFD for ; Fri, 2 Mar 2018 03:25:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.121 X-Spam-Level: X-Spam-Status: No, score=-0.121 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id 1NaNevSsjcGX for ; Fri, 2 Mar 2018 03:25:16 +0000 (UTC) Received: from mail-ua0-f180.google.com (mail-ua0-f180.google.com [209.85.217.180]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 37FB45F173 for ; Fri, 2 Mar 2018 03:25:16 +0000 (UTC) Received: by mail-ua0-f180.google.com with SMTP id b23so5295234uak.9 for ; Thu, 01 Mar 2018 19:25:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NjpLJ9EnPcC0rIn1QbkcdhcqQh/SzNGoIopUBXVpcIo=; b=COiU5tJJIlvARPDo2WR71et+MdsNtuGMO3VU1cJSfCk9/yWYEhcFSqnHpFvANx83Gs eLeRIBEYnhkpuKqWxv+u09vB92WFZTmP7e0OYGbBJpQKaV5DcaiSm3THYiOxRs3tK2dl 9wBTD/M7SlgqWg2ruBfdlQwRgGTu9pPnk+rzyt5TaUCCQgixclzD0MVNXMJ3vJptPikL gCCIgQUIoehfua9wvLMc+sUhoRKxuJhH1GdzBqc2wPn7bTj2r2OYAb1OmRBXn2OkOF3S 0zoPvmQgjYi9IggtzD0xsZU0tu37JhJedg9Y8XNAJb/bE3D+AqaesQMRi/ppkWOlggkR gtgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NjpLJ9EnPcC0rIn1QbkcdhcqQh/SzNGoIopUBXVpcIo=; b=l5kgLzpNJRm4OUh3pEnd1Evty+0YPI1+PwWCoAQe0/L+yyX9S2W4eyIoqMgsgIyvfN DllOfSMraceSsq8S8geKyHwRy4mqE1JgxKDczwip+sHHlXGw/C+l8UET3GNVlt7Q3qT+ 8BEfzDD1tMVataoWWoIVd9baGZ2h9QAbY7hfV43GO0+5eAY54vdt9XtHCjBSCpKcCi/h KK9r0I4Wid0SwQ3AeE7wiTRd2A0PSt092IRdJLDpxkG689iaEwzBY5O2g5YfQNHZsBqK PtSWemncHXQW8MqMLBfNBPzXx81RB11eCV1IxvqqrZn+9MX0/MG97EP3gNRRsIkyPj+w DGPQ== X-Gm-Message-State: AElRT7EGRa5L0aLzS6Tz/6DabLelpc7Sp/oNpwKrffApMUJQdl7Jo0+B uBYfd5xRyDBbOzx7BCq5nJR6dqpeQmvOzi7S7rc= X-Google-Smtp-Source: AG47ELutyZOmCoFFf4hZ1NXWRW8CeckcEjXs3WgYtdlX7AmpGfYa+3iG8Rln7JvGjSbYIK+ug4n5mP0oEc4RyT8Ug2M= X-Received: by 10.159.35.230 with SMTP id 93mr2961562uao.63.1519961109910; Thu, 01 Mar 2018 19:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.7.221 with HTTP; Thu, 1 Mar 2018 19:25:09 -0800 (PST) In-Reply-To: References: <20180223212514.GB12938@ted.stsp.name> <87k1v3l3rd.fsf@codematters.co.uk> <87d10vkx50.fsf@codematters.co.uk> <87606nkvth.fsf@codematters.co.uk> <87lgfeilm8.fsf@codematters.co.uk> From: Myria Date: Thu, 1 Mar 2018 19:25:09 -0800 Message-ID: Subject: Re: SHA-1 collision in repository? To: Nico Kadel-Garcia Cc: Philip Martin , Matt Simmons , Subversion Content-Type: text/plain; charset="UTF-8" I just found out that the file causing the error from the large commit is not the large file - it's one of the smaller files, about 55 KB. If I commit that single smaller file from the large commit, it errors the same way as the original 227185 would. This is exactly like the original problem with committing the pixel shader. I managed to get the db/transactions/227184-4vb2.txn directory by breakpointing kernel32!DeleteFileW in TortoiseSVN (so I could get the contents before TortoiseSVN deleted them at failure). I don't know how they're useful, though. The only way I know how to proceed is to wait until the source code to TortoiseSVN is available so that I can debug it in Visual Studio. Is there something else I can do? On Thu, Mar 1, 2018 at 6:45 PM, Myria wrote: > On Wed, Feb 28, 2018 at 6:17 AM, Nico Kadel-Garcia wrote: >> On Tue, Feb 27, 2018 at 4:09 PM, Myria wrote: >> >>> Not to mention that the two revisions complained about are unrelated, and >>> 2/3 the repository history apart. >>> >>> One thing that's interesting is that the commit the svnsync failed on is a >>> gigantic commit. It's 1.8 GB. Maybe that svnsync is failing because of a >>> Subversion bug with huge files...? >> >> Hmm. Could 2 GB filesize limites be involved? >> >> When someone starts encountering this kind of issue with such large >> commits, it leads me to think "what the heck was in that commit"? >> There are various tools more likely to break when hammered that hard, >> wuch as pre-commit hooks written carelessly in Python that try to >> preload a hash with the contents of the file and just say "holy sone >> of a !@#$, I'm out of resources!!!". Been there, done that, had to >> explain the concept of reading a text file with a loop to the >> programmer in question. >> > > The error with the 2 GB file occurred when trying to replicate the > repository in order to diagnose the original problem. The original > problem does not involve large files. > > Also, I have no control over what was in the repository five years > ago. The huge files were compiled versions of WebKit libraries. The > alternative to committing these very large files would have been to > quadruple the build times, because it takes four times longer to build > WebKit than it does to build our project. > > > In other news, I can now reproduce the huge file problem in > TortoiseSVN committing to my "file:" partial copy of the repository. > However, with SourceForge down due to a DDoS, I cannot get the source > code to TortoiseSVN in order to debug it. > > This does mean that this is very likely to be a Subversion bug, > probably something in 1.8.x or 1.9.x. The commit that prevented > "svnsync" from working was probably during 1.6 or 1.7, which > succeeded. > > Melissa