[bitbake-devel] hg fetcher failures for SRCREV set to a tag

[Richard Purdie]

On Wed, 2012-12-05 at 19:17 -0500, Jon Szymaniak wrote:
> tl;dr: Doesn't the "update" in lines 142-147 of hg.py cause issues when
> SRCREV is a tag?
> 
> 
> Hi all,
> 
> I didn't have any luck with this post on the Yocto mailing list. Since it seems
> more like a bitbake issue (I'm very hesitant to cry "bug" at this point),
> I hope I'm in the right place.
> 
> I've been running into "Fetcher failures" for my recipes using
> mercurial recently, which report that I'm asking for an unknown revision,
> despite it being valid. A trimmed log is at the end of this post.
> 
> After looking at hg.py, it seems the issue is that the
> 'hg update -r MY_TAG' that follows the 'hg clone -r MY_TAG ...' is doomed to
> fail because that tag isn't visible until the next rev, where the action of
> tagging it is committed.
> 
> For example, if I clone v1.1.0, I won't see that tag because the tag is added
> to .hgtags in commit 41:58b..
> 
>       tip                             41:58b8f368be68
>       v1.1.0                        40:a925b596c163
>       v1.0.4                        39:6bf84da2571e
> 
> Therefore once I've cloned with "-r v1.1.0", I can't do an update
> specifying tag v1.1.0.
> 
> Does this sound right, or am I way off here?
> 
> I'm not sure if using a tag rather than the revision number is unorthodox or
> abnormal for bb's, so below's my use case, for a my-app_0.1.2.bb
> 
> require my-app.inc
> PR = "${INC_PR}.0"
> SRCREV = "v${PV}"
> 
> Therefore to bring in a new version, I can simply copy this file to a
> my-app_1.1.0.bb, and adjust PR back to 0 if needed.
> 
> We have a policy not to move version tags, so tag-->revision should be 1:1. Is
> what I'm seeing a non-issue simply because one shouldn't use tags in SRCREV?
> 

FWIW, the hg fetcher is a little unloved. We don't have many developers
who use it or are familiar with how hg works. If there are some ways we
can fix things I'd be interested in patches.

I'm afraid I haven't had a chance to look at the details of the above
yet though.

Cheers,

Richard