From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail1.windriver.com ([147.11.146.13]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1Ue9O8-00086p-JV for bitbake-devel@lists.openembedded.org; Sun, 19 May 2013 21:35:28 +0200 Received: from ALA-HCA.corp.ad.wrs.com (ala-hca.corp.ad.wrs.com [147.11.189.40]) by mail1.windriver.com (8.14.5/8.14.3) with ESMTP id r4JG2Sd8012613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 19 May 2013 09:02:28 -0700 (PDT) Received: from bruce-ashfields-macbook.local (128.224.21.35) by ALA-HCA.corp.ad.wrs.com (147.11.189.50) with Microsoft SMTP Server id 14.2.342.3; Sun, 19 May 2013 09:02:27 -0700 Message-ID: <5198F792.20601@windriver.com> Date: Sun, 19 May 2013 12:02:26 -0400 From: Bruce Ashfield User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Richard Purdie References: <1368958915.32727.96.camel@ted> In-Reply-To: <1368958915.32727.96.camel@ted> Cc: "Hart, Darren" , Koen Kooi , bitbake-devel , Martin Jansa Subject: Re: [PATCH] fetch2: Shorten long srcrevs X-BeenThere: bitbake-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 May 2013 19:35:51 -0000 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit On 13-05-19 6:21 AM, Richard Purdie wrote: > The long srcrevs are mainly used or the workdir construction as well as > the package version. The long entries are hashes generated by the git fetcher > and other scms using a similar revision mechanism. > > We need these to change when the package changes however collisions are > unlikely to happen within the domains we care about. The long revisions > have generated negative user feedback due to the use in path and file > names. > > This patch therefore truncates the revisions to 10 characters maximum. > > This should be safe in the contexts where these revisions are used as > the chances of spatially close collisions is very low (distant > collisions are not a major issue in the way we use these). I for one like the change, the split of PN/ was a nice improvement and this will make life a little bit easier again. 10 should definitely be enough to avoid collisions, I've rarely had to go above 7 or 8 characters in my kernel hashes, and 10 will make collisions that much harder to find. As Martin asked, I assume we continue to specify 40 character hashes in our recipes, which is fine with me since it makes the recipe completely accurate. Cheers, Bruce > > Signed-off-by: Richard Purdie > --- > CC'd various people who I believe might have feelings about this. The > patch depends on the sortable_revisions patch I just sent out. > > diff --git a/bitbake/lib/bb/fetch2/__init__.py b/bitbake/lib/bb/fetch2/__init__.py > index f8f8244..402329d 100644 > --- a/bitbake/lib/bb/fetch2/__init__.py > +++ b/bitbake/lib/bb/fetch2/__init__.py > @@ -617,6 +617,8 @@ def get_srcrev(d): > > if len(scms) == 1 and len(urldata[scms[0]].names) == 1: > autoinc, rev = urldata[scms[0]].method.sortable_revision(scms[0], urldata[scms[0]], d, urldata[scms[0]].names[0]) > + if len(rev) > 10: > + rev = rev[:10] > if autoinc: > return "AUTOINC+" + rev > return rev > @@ -633,6 +635,8 @@ def get_srcrev(d): > ud = urldata[scm] > for name in ud.names: > autoinc, rev = ud.method.sortable_revision(scm, ud, d, name) > + if len(rev) > 10: > + rev = rev[:10] > if autoinc and not seenautoinc: > rev = "AUTOINC+" + rev > seenautoinc > >