support/downlaod: fix the Hg backend for tags
PATCH 1/1 support/downlaod: fix the Hg backend for tags
When the version of a package is a Mercurial tag, the download fails, with:
abort: unknown revision 'X.Y.Z'!
This is because, in Mercurial, tags are commits like the others, and when we clone, we actively request a tag. But then, the server "dereferences" that tag and sends us the revision pointed to by that tag. Of course, since the tag is a commit after the revision we got, we do not have the revision adding the tag.
So, we just have to download the full repository to be sure we have the tags in our local clone.
--- support/download/hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
support/download/hg +1 -1
@@ -25,7 +25,7 @@ repo="${2}" cset="${3}" basename="${4}" -${HG} clone ${verbose} --noupdate --rev "${cset}" "${repo}" "${basename}" +${HG} clone ${verbose} --noupdate "${repo}" "${basename}" ${HG} archive ${verbose} --repository "${basename}" --type tgz \ --prefix "${basename}" --rev "${cset}" \
Signature · 1 line
1.9.1
PATCH 1/1 support/downlaod: fix the Hg backend for tags
[Putting our Mercurial expert in Cc]
Quoted 24 lines · Yann E. MORIN
When the version of a package is a Mercurial tag, the download fails, with:
abort: unknown revision 'X.Y.Z'!This is because, in Mercurial, tags are commits like the others, and when we clone, we actively request a tag. But then, the server "dereferences" that tag and sends us the revision pointed to by that tag. Of course, since the tag is a commit after the revision we got, we do not have the revision adding the tag.
So, we just have to download the full repository to be sure we have the tags in our local clone.
Reported-by Thomas Petazzoni <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>--- support/download/hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)support/download/hg +0
-0
support/download/hg repo="${2}" · line 31
Quoted 8 lines
support/download/hg +1
-1@@ -25,7 +25,7 @@ repo="${2}" cset="${3}" basename="${4}" -${HG} clone ${verbose} --noupdate --rev "${cset}" "${repo}" "${basename}" +${HG} clone ${verbose} --noupdate "${repo}" "${basename}" ${HG} archive ${verbose} --repository "${basename}" --type tgz \ --prefix "${basename}" --rev "${cset}" \
Wouldn't it be better to stick to the original way of cloning, and instead
specify the equivalent of HEAD as --rev here? I think that would even be the default, no?
Regards,
Arnout
Quoted 1 line
Signature · 6 lines
Arnout Vandecappelle arnout at mind be Senior Embedded Software Architect +32-16-286500 Essensium/Mind http://www.mind.be G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
PATCH 1/1 support/downlaod: fix the Hg backend for tags
Arnout, All,
On 2015-08-23 00:47 +0200, Arnout Vandecappelle spake thusly:
Quoted 31 lines · Yann E. MORIN
Quoted 30 lines
When the version of a package is a Mercurial tag, the download fails, with:
abort: unknown revision 'X.Y.Z'!This is because, in Mercurial, tags are commits like the others, and when we clone, we actively request a tag. But then, the server "dereferences" that tag and sends us the revision pointed to by that tag. Of course, since the tag is a commit after the revision we got, we do not have the revision adding the tag.
So, we just have to download the full repository to be sure we have the tags in our local clone.
Reported-by Thomas Petazzoni <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>--- support/download/hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)support/download/hg +1
-1@@ -25,7 +25,7 @@ repo="${2}" cset="${3}" basename="${4}" -${HG} clone ${verbose} --noupdate --rev "${cset}" "${repo}" "${basename}" +${HG} clone ${verbose} --noupdate "${repo}" "${basename}"
Quoted 6 lines
support/download/hg repo="${2}" · line 31
Quoted 2 lines
support/download/hg +0
-0${HG} archive ${verbose} --repository "${basename}" --type tgz \ --prefix "${basename}" --rev "${cset}" \Wouldn't it be better to stick to the original way of cloning, and instead
specify the equivalent of HEAD as --rev here? I think that would even be the default, no?
That would be 'tip' in Mercurial parlance.
And yes, worth a try...
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
PATCH 1/1 support/downlaod: fix the Hg backend for tags
In reply to Arnout VandecappelleArnout, All,
On 2015-08-23 00:47 +0200, Arnout Vandecappelle spake thusly:
Quoted 31 lines · Yann E. MORIN
Quoted 30 lines
When the version of a package is a Mercurial tag, the download fails, with:
abort: unknown revision 'X.Y.Z'!This is because, in Mercurial, tags are commits like the others, and when we clone, we actively request a tag. But then, the server "dereferences" that tag and sends us the revision pointed to by that tag. Of course, since the tag is a commit after the revision we got, we do not have the revision adding the tag.
So, we just have to download the full repository to be sure we have the tags in our local clone.
Reported-by Thomas Petazzoni <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>--- support/download/hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)support/download/hg +1
-1@@ -25,7 +25,7 @@ repo="${2}" cset="${3}" basename="${4}" -${HG} clone ${verbose} --noupdate --rev "${cset}" "${repo}" "${basename}" +${HG} clone ${verbose} --noupdate "${repo}" "${basename}"
Quoted 6 lines
support/download/hg repo="${2}" · line 31
Quoted 2 lines
support/download/hg +0
-0${HG} archive ${verbose} --repository "${basename}" --type tgz \ --prefix "${basename}" --rev "${cset}" \Wouldn't it be better to stick to the original way of cloning, and instead
specify the equivalent of HEAD as --rev here? I think that would even be the default, no?
OK, I tried using "--rev tip" and it does work.
There's a very slight difference when cloning eigen; they have a .hgarchival.txt file that contains some info about the repo, and that file slightly differs in both cases. Since it is a file generated by Mercurial, and it is not in the repository, it's not a big problem.
Still, I think the cleanest is the patch I proposed.
Regards,
Yann E. MORIN.
Signature · 6 lines
.-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'
Thomas Petazzoni
AppliedPATCH 1/1 support/downlaod: fix the Hg backend for tags
In reply to Yann E. MORINDear Yann E. MORIN,
Quoted 10 lines · Yann E. MORIN
When the version of a package is a Mercurial tag, the download fails, with:
abort: unknown revision 'X.Y.Z'!This is because, in Mercurial, tags are commits like the others, and when we clone, we actively request a tag. But then, the server "dereferences" that tag and sends us the revision pointed to by that tag. Of course, since the tag is a commit after the revision we got, we do not have the revision adding the tag.
Quoted 8 lines
So, we just have to download the full repository to be sure we have the tags in our local clone.
Reported-by Thomas Petazzoni <[email protected]>Signed-off-by "Yann E. MORIN" <[email protected]>--- support/download/hg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Applied to next, thanks (after fixing the minor typo in the commit title). I've also committed a follow-up patch that makes the eigen package use a Mercurial tag.
Thanks!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com