Re: AUTOREV and SRCPV

[Martin Jansa <martin.jansa@gmail.com>]

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:
> > > On Thursday 03 June 2010 06:35:05 Martin Jansa wrote:
> 
> <snip>
> 
> But if you then decide to remove BB_GIT_CLONE_FOR_SRCREV again because you 
> no longer need it, and somebody starts a clean build, the LOCALCOUNT would 
> start at 0 again I guess.

SRCPV is storing LOCALCOUNT in the same persistent db as AUTOREV with or without
BB_GIT_CLONE_FOR_SRCREV (at least for bitbake-1.10 and higher). The
BB_GIT_CLONE_FOR_SRCREV caching changed that you won't count revisions
if the requested SRCREV (latest for AUTOREV or specified in recipe) is
the same as was for last parsing and so the same LOCALCOUNT can be taken
from persistent db.

I'm not sure if 1.8 was storing LOCALCOUNT from BB_GIT_CLONE_FOR_SRCREV
but then never used it from db (then switching BB_GIT_CLONE_FOR_SRCREV
off would keep same LOCALCOUNTs) or if it didn't even store it (less
likely - but you can easily check).

Either way if you upgrade bitbake first (while keeping
BB_GIT_CLONE_FOR_SRCREV) and then switch BB_GIT_CLONE_FOR_SRCREV off,
you should have same LOCALCOUNTs


> So the versioning isn't consistent anyway when toggling 
> BB_GIT_CLONE_FOR_SRCREV.
> 
> > The other is when you change SRCREV in recipe without updating PV. Then
> > SRCPV will give you newer PV which will upgrade resulting package on
> > target.
> 
> Yes, but only if you stick to the same buildserver, and as soon as the hdd 
> crashes for instance and you have to start with a clean build, everybody is 
> in trouble.

Yes and that's the same for AUTOREV (without BB_GIT_CLONE_FOR_SRCREV).

> 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.

> 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).

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).

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

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa