<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Dec 14, 2012 at 12:09 PM, Jon Szymaniak <span dir="ltr"><<a href="mailto:jon.szymaniak@gmail.com" target="_blank">jon.szymaniak@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="h5">>> tl;dr: Doesn't the "update" in lines 142-147 of hg.py cause issues when<br>
>> SRCREV is a tag?<br>
>><br>
>><br>
>> Hi all,<br>
>><br>
>> I didn't have any luck with this post on the Yocto mailing list. Since it seems<br>
>> more like a bitbake issue (I'm very hesitant to cry "bug" at this point),<br>
>> I hope I'm in the right place.<br>
>><br>
>> I've been running into "Fetcher failures" for my recipes using<br>
>> mercurial recently, which report that I'm asking for an unknown revision,<br>
>> despite it being valid. A trimmed log is at the end of this post.<br>
>><br>
>> After looking at hg.py, it seems the issue is that the<br>
>> 'hg update -r MY_TAG' that follows the 'hg clone -r MY_TAG ...' is doomed to<br>
>> fail because that tag isn't visible until the next rev, where the action of<br>
>> tagging it is committed.<br>
>><br>
>> For example, if I clone v1.1.0, I won't see that tag because the tag is added<br>
>> to .hgtags in commit 41:58b..<br>
>><br>
>> tip 41:58b8f368be68<br>
>> v1.1.0 40:a925b596c163<br>
>> v1.0.4 39:6bf84da2571e<br>
>><br>
>> Therefore once I've cloned with "-r v1.1.0", I can't do an update<br>
>> specifying tag v1.1.0.<br>
>><br>
>> Does this sound right, or am I way off here?<br>
>><br>
>> I'm not sure if using a tag rather than the revision number is unorthodox or<br>
>> abnormal for bb's, so below's my use case, for a <a href="http://my-app_0.1.2.bb" target="_blank">my-app_0.1.2.bb</a><br>
>><br>
>> require my-app.inc<br>
>> PR = "${INC_PR}.0"<br>
>> SRCREV = "v${PV}"<br>
>><br>
>> Therefore to bring in a new version, I can simply copy this file to a<br>
>> <a href="http://my-app_1.1.0.bb" target="_blank">my-app_1.1.0.bb</a>, and adjust PR back to 0 if needed.<br>
>><br>
>> We have a policy not to move version tags, so tag-->revision should be 1:1. Is<br>
>> what I'm seeing a non-issue simply because one shouldn't use tags in SRCREV?<br>
>><br>
><br>
> FWIW, the hg fetcher is a little unloved. We don't have many developers<br>
> who use it or are familiar with how hg works. If there are some ways we<br>
> can fix things I'd be interested in patches.<br>
><br>
> I'm afraid I haven't had a chance to look at the details of the above<br>
> yet though.<br>
><br>
> Cheers,<br>
><br>
> Richard<br>
><br>
<br>
</div></div>Hi Richard,<br>
<br>
Thanks for pinging back on this. (Sorry I just double-sent this to<br>
you. Forgot to include the list! :P)<br>
<br>
I think a fairly simple solution might be to just clone the entire<br>
repo by not adding "-r REV" to options[] for an 'hg clone' invocation.<br>
The 'hg update' that follows on lines 142-147 should set the repo to<br>
the desired revision.</blockquote></div><br>This does sound like the best bet, to me.<br>-- <br>Christopher Larson<br>
</div>