7008 2014-12-02 12:42:40 +0000 hg fetch always returns "tip" of repository 2015-02-04 18:28:11 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED NOTABUG Medium normal 1.8 M3 1 sschreiber anibal.limon poky.bs.watcher poky.watcher sgw --- --- Don't know oldest_to_newest 47284 0 sschreiber 2014-12-02 12:42:40 +0000 I'm not sure if this is a bug or intended behavior: bb.fetch2.hg.Hg()._latest_revision() always returns the revision of the 'tip' of a repository. In our case this is problematic: we have SRC_URIs with a ;tag="default", but in repositories where 'tip' points to another branch, e.g. some feature branch with more recent commits, the wrong revision is returned. We avoid this problem by passing the user-specified revision to the hg identify command in _latest_revision(): --- a/yocto/bitbake/lib/bb/fetch2/hg.py Tue Dec 02 11:01:39 2014 +0100 +++ b/yocto/bitbake/lib/bb/fetch2/hg.py Tue Dec 02 11:03:48 2014 +0100 @@ -98,7 +98,7 @@ hgroot = ud.user + "@" + host + ud.path if command == "info": - return "%s identify -i %s://%s/%s" % (basecmd, proto, hgroot, ud.module) + return "%s identify -i %s://%s/%s --rev %s" % (basecmd, proto, hgroot, ud.module, ud.revision) options = []; 48558 1 anibal.limon 2015-02-04 18:28:11 +0000 Hi Sebastian, The current behavior is right because if you specify a rev for get latest_revision returns the same rev that you specify. In mercurial named revisions are tags. The issue here is that the current code don't handle mercurial branches with this support you can specify a branch and get the latest_revision associated with this branch. Kind regards, alimon