| Summary: | hg fetch always returns "tip" of repository | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Sebastian Schreiber <sschreiber> |
| Component: | bitbake | Assignee: | Aníbal Limón <anibal.limon> |
| Status: | RESOLVED NOTABUG | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher, sgw |
| Version: | unspecified | ||
| Target Milestone: | 1.8 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
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
|
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 = [];