From owner-svn-src-head@FreeBSD.ORG Tue Jul 15 23:28:04 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E59C5D0F; Tue, 15 Jul 2014 23:28:04 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1C462152; Tue, 15 Jul 2014 23:28:04 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id w10so144038pde.4 for ; Tue, 15 Jul 2014 16:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=t3ZI+uCRh1UeRAF0EKNHgxodpCxPyJjdT2+Pzc/1OiY=; b=Ie170jcM4XAvyzyP+0b/ZxRzJbNAWVQAEc1/6Gtdbc9cVCVbFEMf9APLhVsFEOoz9K qEfHYAgjD0m9c1vzLJBoMV46J8d/uQIVGu1l9Xmu1L3sn32CI76MLaJOTUYwvHQyVIMx 4yYds8GDkpzq5NuS8pOBqqb0k5lcJmSaOR+KhlFxCOGK+TeO745WmrxrRF7UU8yvzHDn vJzWXkdx6vz9dvLj9FGDpnQW2HWZqmYs2JbABNI10YcFC/Z+Q9gxZhJtrubucc6pG6oo 5VMaPlLGlxuT4x6lYqQoFX3BGZlr7jR9P9kRBLl86L4dSFheT87IDtK/Pui7BSkpak+j 4zdg== X-Received: by 10.68.138.227 with SMTP id qt3mr26176229pbb.6.1405466884157; Tue, 15 Jul 2014 16:28:04 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id w7sm18514131pdo.90.2014.07.15.16.28.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jul 2014 16:28:03 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <53C5B8FD.7070809@FreeBSD.org> Date: Wed, 16 Jul 2014 09:27:57 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: John Baldwin , Baptiste Daroussin Subject: Re: Phabric IDs / URLs in commits References: <201407111616.s6BGGQFW060195@svn.freebsd.org> <201407111238.23391.jhb@freebsd.org> <20140711175442.GJ93051@ivaldir.etoilebsd.net> <201407151112.51824.jhb@freebsd.org> In-Reply-To: <201407151112.51824.jhb@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2014 23:28:05 -0000 On 16/07/2014 1:12 AM, John Baldwin wrote: > On Friday, July 11, 2014 1:54:42 pm Baptiste Daroussin wrote: >> On Fri, Jul 11, 2014 at 12:38:23PM -0400, John Baldwin wrote: >>> On Friday, July 11, 2014 12:16:26 pm John Baldwin wrote: >>>> Author: jhb >>>> Date: Fri Jul 11 16:16:26 2014 >>>> New Revision: 268531 >>>> URL: http://svnweb.freebsd.org/changeset/base/268531 >>>> >>>> Log: >>>> Fix some edge cases with rewinddir(): >>>> - In the unionfs case, opendir() and fdopendir() read the directory's full >>>> contents and cache it. This cache is not refreshed when rewinddir() is >>>> called, so rewinddir() will not notice updates to a directory. Fix this >>>> by splitting the code to fetch a directory's contents out of >>>> __opendir_common() into a new _filldir() function and call this from >>>> rewinddir() when operating on a unionfs directory. >>>> - If rewinddir() is called on a directory opened with fdopendir() before >>>> any directory entries are fetched, rewinddir() will not adjust the seek >>>> location of the backing file descriptor. If the file descriptor passed >>>> to fdopendir() had a non-zero offset, the rewinddir() will not rewind to >>>> the beginning. Fix this by always seeking back to 0 in rewinddir(). >>>> This means the dd_rewind hack can also be removed. >>>> >>>> While here, add missing locking to rewinddir(). >>>> >>>> CR: https://phabric.freebsd.org/D312 >>>> Reviewed by: jilles >>>> MFC after: 1 week >>> >>> Just picking my own commit here as a sample case. >>> >>> I think we should be annotating commits with phabricator code reviews in some >>> way when a change has gone through that review. It is very useful to get back >>> to the review details from the commit log message in svnweb, etc. >>> >>> I can see a number of different ways to do this, but I do think it would be >>> nice to pick a consistent way to do it. >>> >>> Things to consider: >>> >>> 1) The tag ("CR:" is what I used above). I don't care, just pick one. I >>> chose CR since Warner used it previously. Whatever we decide, we should >>> add it to the template. >>> >>> 2) ID vs full URL. For PRs we just list the bug ID and not the full URL >>> (same for Coverity). I would be fine with that so long as someone hacks >>> up svnweb to convert the IDs into links (the way it handles PR bug >>> numbers). OTOH, if you use the full URL you get that for free in svnweb, >>> and you also get it in mail clients, etc. It helps that the URL isn't but >>> so long. >> >> for bugs we could use http://bugs.FreeBSD.org/ that also works and it is >> short :) > > Ok, so Bryan said ports uses 'Phabric: Dxxx' and I read Baptiste's e-mail as a > preference for the URL itself (no preference on the prefix though?) Any other > thoughts? I probably lean towards the full URL personally since it requires less > work (no hacking on svnweb) and works out-of-the-box in more forums (e-mail, etc.) > +100 on CR: without URL's to keep them decoupled and forever valid in the (probably very likely) case we change hostnames/urls. I'm liking phabric so far, but would opt for a more concrete review.freebsd.org if I had the choice (and when it's ready). This way our "review" processes and workflows can be extended or modified orthogonal to the tool in use.