diff options
author | Richard Purdie <richard@openedhand.com> | 2008-09-10 16:25:46 +0000 |
---|---|---|
committer | Richard Purdie <richard@openedhand.com> | 2008-09-10 16:25:46 +0000 |
commit | 22e0395343b2c182eefe3e34625713b6185ccbd5 (patch) | |
tree | da4c63187f1d0ac44e10c1768a8fdab74618aef9 /meta-extras/packages/minicom | |
parent | f09c00eb870c400777b67e48907113f4a6ed2ada (diff) | |
download | openembedded-core-22e0395343b2c182eefe3e34625713b6185ccbd5.tar.gz openembedded-core-22e0395343b2c182eefe3e34625713b6185ccbd5.tar.bz2 openembedded-core-22e0395343b2c182eefe3e34625713b6185ccbd5.tar.xz openembedded-core-22e0395343b2c182eefe3e34625713b6185ccbd5.zip |
bitbake hg fetcher: Add fix from Matt Hoosier
The Mercurial fetcher right now will fail when used to incrementally
fetch an update to a local clone of a repository already fetched at
some prior revision. The culprit is the sequence:
hg pull -r <rev>
hg update -C <rev>
A subtlety in the way that Mercurial stores its tags (in a normally
version-controlled file called .hgtags) has the side-effect that a
repository fetched at a tag "foo" will not actually contain a
new-enough copy of the .hgtags file to be self-aware of the foo tag's
existence.
The solution is just to get all the changesets in the repository on
incremental upgrades, so that the following "hg update" will be able
to resolve the tag.
git-svn-id: https://svn.o-hand.com/repos/poky/trunk@5170 311d38ba-8fff-0310-9ca6-ca027cbcb966
Diffstat (limited to 'meta-extras/packages/minicom')
0 files changed, 0 insertions, 0 deletions