[yocto] Fetcher failure for mercurial repos: 'unknown revision' due to -r <SRCREV> in both clone and update?

[Jon Szymaniak]

I've been running into "Fetcher failures" for my recipes using
mercurial recently. They only seem to crop up the first time a package
that comes from a hg repo is fetched.

I believe the issue stems from the combination of the arguments used
by the hg fetcher and the fact that I specified a tag rather than
revision number.

I've included a "trimmed" log at the end of this post, where I've
pruned out useless and personal information. Here are some of of my
comments and questions. I'm no mercurial expert, so please do correct
me if and where I'm wrong!

- Why is GIT_CONFIG being exported for mercurial invocations?
- I think the 'clone -r v1.1.0' followed by the 'update -C -r v1.1.0'
is possibly responsible for the failure.
  - In mercurial, the tag is a commit after the revision that's being tagged.
      tip                               41:58b8f368be68
      v1.1.0                          40:a925b596c163
      v1.0.4                          39:6bf84da2571e
  - In the above, rev 41 contains the action of tagging 40 as 'v1.1.0'
  - Therefore, if we clone the version associated with tag v1.1.0, we
get rev 40 and earlier. At this point, there's no "knowledge" of there
being a 'v1.1.0' tag!
    - As such, the 'hg update -C -r v1.1.0' that follows the 'hg clone
-r v1.1.0' fails.

- One possible fix might be to remove the "-r <rev>" usage from the hg
fetcher. (lines 101 and 102 in bitbake/lib/bb/fetch2/hg.py)
  - A fetch always follows an update to the revision anyway, doesn't
it. (Per comment @ lines 142-143).
  - Con: You have to fetch the whole darn repo. It makes sense that we
wouldn't want to do that when we don't have to. :)
  - Pro: You'll  have the revision you wanted.
  - Disclaimer: I'm not familiar enough with this code to know whether
this would cause undesired side effects or break things!

- Workaround: Don't use tags in SRCREV
  - This stinks, because I like to write my .bb's as follows, so that
updating a version is just a matter of copy/renaming the .bb
        require <my_package>.inc
        PR = "${INC_PR}.0"
        SRCREV = "v${PV}"

DEBUG: Fetch: checking for module directory
'/export/home/jon/projects/yocto/poky/build/test/downloads/hg/host/some_dir/my_package'
NOTE: Fetch hg://hg@host/some_dir;module=my_package;protocol=ssh
DEBUG: Running /usr/bin/env hg clone -r v1.1.0
ssh://hg@host/some_dir/my_package my_package
DEBUG: Fetcher accessed the network with the command /usr/bin/env hg
clone -r v1.1.0 ssh://hg@host/some_dir/my_package my_package
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg clone -r v1.1.0 ssh://hg@host/some_dir/my_package
my_package
DEBUG: Running /usr/bin/env hg update -C -r v1.1.0
DEBUG: Running export HOME="/export/home/jon"; export
SSH_AGENT_PID="1234"; export SSH_AUTH_SOCK="<snipped>"; export
GIT_CONFIG="<snipped>/gitconfig"; export PATH="<snipped>";
/usr/bin/env hg update -C -r v1.1.0
WARNING: Failed to fetch URL
hg://hg@host/some_dir;module=my_package;protocol=ssh, attempting
MIRRORS if available
DEBUG: Fetcher failure: Fetch command failed with exit code 255, output:
abort: unknown revision 'v1.1.0'!

DEBUG: Python function base_do_fetch finished
DEBUG: Python function do_fetch finished
ERROR: Function failed: Fetcher failure for URL:
'hg://hg@host/some_dir;module=my_package;protocol=ssh'. Unable to
fetch URL from any source.


Thank you,
Jon