Return-Path: X-Original-To: apmail-subversion-dev-archive@minotaur.apache.org Delivered-To: apmail-subversion-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0A0D3186AC for ; Fri, 7 Aug 2015 09:57:28 +0000 (UTC) Received: (qmail 71747 invoked by uid 500); 7 Aug 2015 09:57:18 -0000 Delivered-To: apmail-subversion-dev-archive@subversion.apache.org Received: (qmail 71700 invoked by uid 500); 7 Aug 2015 09:57:18 -0000 Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@subversion.apache.org Received: (qmail 71690 invoked by uid 99); 7 Aug 2015 09:57:18 -0000 Received: from Unknown (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 07 Aug 2015 09:57:18 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 8644219DDD4 for ; Fri, 7 Aug 2015 09:57:17 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=6.31 tests=[UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=disabled Received: from mx1-us-west.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id Rf2nJ6rQoOJm for ; Fri, 7 Aug 2015 09:57:09 +0000 (UTC) Received: from einhorn.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) by mx1-us-west.apache.org (ASF Mail Server at mx1-us-west.apache.org) with ESMTPS id E85E42092B for ; Fri, 7 Aug 2015 09:57:08 +0000 (UTC) X-Envelope-From: stsp@elego.de Received: from fintan.stsp.name (fintan.stsp.name [217.197.84.44]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t779v2N3011824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 7 Aug 2015 11:57:05 +0200 Received: from localhost (fintan.stsp.name [local]) by fintan.stsp.name (OpenSMTPD) with ESMTPA id 51819d60; Fri, 7 Aug 2015 11:57:00 +0200 (CEST) Date: Fri, 7 Aug 2015 11:57:00 +0200 From: Stefan Sperling To: Brett Randall Cc: dev@subversion.apache.org Subject: Re: [patch][reboot-topic] fix check-mime-type.pl for changes to 'svnlook proplist' output Message-ID: <20150807095659.GC4573@fintan.stsp.name> Mail-Followup-To: Brett Randall , dev@subversion.apache.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) On Fri, Aug 07, 2015 at 03:25:19PM +1000, Brett Randall wrote: > On the mailing list back in March 2014, there was a thread[1] which > correctly observed that since r1416637 (released in 1.7.8), the > changed output of svnlook proplist from name : value format to a new > multi-line/multi-value format made the existing check-mime-type.pl > contrib pre-commit hook script no longer worked correctly, as it could > no longer parse the multi-line proplist output. > > A patch was proposed[2], which took the approach of using svnlook > proget instead of svnlook proplist. After some feedback, the thread > went cold, and there's no evidence of a commit or tracking bug. > > I took a look at the patch and a similar approach. I found that > svnlook propget, if it does not find the property present, sets return > code = 1, which is caught in read_from_process causing the script to > fail immediately. Perhaps that was how it was intended to work. > > The patch also contains a behaviour change, from working only on added > files in the transaction, to now working with any updated files also. > > Having found the contrib script non-functional, I've taken another > look at this, and pushed a potential fix to my clone on Github[3]. > This works for me for Subversion/svnlook 1.6.11 (old output) and 1.8.8 > (new output). I went with a dual-format parse of svnlook proplist > output, rather than tackling the switch to propget and handling the > return-code. > > So I just wanted to reopen the conversation, to either reopen > discussion/review of the old patch, or start a review of my new patch. > > Thanks > Brett Hi Brett, thanks for your patch. I took a quick look at it. The handling of the output_line index varliable doesn't seem entirely safe. If the output is garbled and ends with a property name but no value then the script might end up using an invalid array index here: if (not $mime_type) { my $next_line_pval_indented = $output[$output_line + 1]; We probably want to add an out-of-bounds check here? Or perhaps perl will report a useful error message by itself? Not sure. BTW, posting patches inline as part of your mail makes review discussion on this mailing list easier. Because we won't have to copy/paste parts of your patch from github into email or run git first to get the code and then copy it. We could just reply in the relevant patch section in mail directly. So please consider submitting your patches as outlined here: http://subversion.apache.org/docs/community-guide/general.html#patches Thanks, Stefan