[oe] AUTOREV and SRCPV

[pieterg]

On Thursday 03 June 2010 10:27:40 Martin Jansa wrote:
> On Thu, Jun 03, 2010 at 10:02:31AM +0200, pieterg wrote:
> > On Thursday 03 June 2010 09:37:17 Martin Jansa wrote:
> > > On Thu, Jun 03, 2010 at 09:15:56AM +0200, pieterg wrote:

<snip>

> > So personally, I would never even want to use SRCPV, unless it's for
> > AUTOREV.
>
> So what you say is that you would also never use AUTOREV without
> BB_GIT_CLONE_FOR_SRCREV, no matter if SRCPV is used.

Right, same reason. I need reproducable versions at all times, on all build 
systems, even when the cache is lost.

> > Would it be an idea to be able to only have BB_GIT_CLONE_FOR_SRCREV for
> > those packages which have SRCREV = ${AUTOREV}?
>
> Well then it will be a bit inconsistent, because those AUTOREV recipes
> will restore their LOCALCOUNT (ie after hdd breakage) but notAUTOREV
> recipes (which usually could be considered more stable) will "downgrade"
> to LOCALCOUNT 0 (if you didn't restore cache).

True, and a bit selfish of course, because I don't care about all those 
SRCPV packages, i cannot even use them because of their inconsistent 
versions.

> A bit better would be to disable LOCALCOUNT_OVERRIDE only for recipes
> you want to be AUTOREV (then git clone will stop for recipes you don't
> care about even with BB_GIT_CLONE_FOR_SRCREV and after removing cache
> those LOCALCOUNT will stay 0 as it was before).

Yes, that would lead to the same workable situation for me.
And seems like an easier fix, because BB_LOCALCOUNT_OVERRIDE is checked for 
each package, where BB_GIT_CLONE_FOR_SRCREV is only checked once, globally.

> Best solution would be to ask git devs to implement "git remote-count
> HASH" as remote-ls works.

Yes, if we could convince them, that would be ideal...

Rgds, Pieter