All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: "Hart, Darren" <darren.hart@intel.com>,
	Koen Kooi <koen@dominion.thruhere.net>,
	bitbake-devel <bitbake-devel@lists.openembedded.org>,
	Martin Jansa <martin.jansa@gmail.com>
Subject: Re: [PATCH] fetch2: Shorten long srcrevs
Date: Sun, 19 May 2013 12:02:26 -0400	[thread overview]
Message-ID: <5198F792.20601@windriver.com> (raw)
In-Reply-To: <1368958915.32727.96.camel@ted>

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/<hashes> 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 <richard.purdie@linuxfoundation.org>
> ---
> 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
>
>




  parent reply	other threads:[~2013-05-19 19:35 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-19 10:21 [PATCH] fetch2: Shorten long srcrevs Richard Purdie
2013-05-19 12:32 ` Martin Jansa
2013-05-20  8:33   ` Richard Purdie
2013-05-20 18:23     ` Darren Hart
2013-05-19 16:02 ` Bruce Ashfield [this message]
2013-05-19 17:07 ` Darren Hart
2013-05-22 19:51 ` Martin Jansa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5198F792.20601@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=bitbake-devel@lists.openembedded.org \
    --cc=darren.hart@intel.com \
    --cc=koen@dominion.thruhere.net \
    --cc=martin.jansa@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.