summaryrefslogtreecommitdiff
path: root/meta-extras/packages/minicom
diff options
context:
space:
mode:
authorRichard Purdie <richard@openedhand.com>2008-09-10 16:25:46 +0000
committerRichard Purdie <richard@openedhand.com>2008-09-10 16:25:46 +0000
commit22e0395343b2c182eefe3e34625713b6185ccbd5 (patch)
treeda4c63187f1d0ac44e10c1768a8fdab74618aef9 /meta-extras/packages/minicom
parentf09c00eb870c400777b67e48907113f4a6ed2ada (diff)
downloadopenembedded-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