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

[Chris Larson]

On Fri, Dec 14, 2012 at 12:09 PM, Jon Szymaniak <jon.szymaniak at gmail.com>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
> >
>
> Hi Richard,
>
> Thanks for pinging back on this. (Sorry I just double-sent this to
> you. Forgot to include the list! :P)
>
> I think a fairly simple solution might be to just clone the entire
> repo by not adding "-r REV" to options[] for an 'hg clone' invocation.
> The 'hg update' that follows on lines 142-147 should set the repo to
> the desired revision.


This does sound like the best bet, to me.
-- 
Christopher Larson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/bitbake-devel/attachments/20121214/ada46b0b/attachment-0001.html>