I have encountered this error when trying to push a subrepository to bitbucket:
D:\Work\agile.crm.framework>hg push
warning: bitbucket.org certificate with fingerprint 81:2b:08:90:dc:d3:71:ee:e0:7
c:b4:75:ce:9b:6c:48:94:56:a1:fe not verified (check hostfingerprints or web.cace
rts config setting)
http authorization required
realm: Bitbucket.org HTTP
user: the_drow
password:
warning: bitbucket.org certificate with fingerprint 81:2b:08:90:dc:d3:71:ee:e0:7
c:b4:75:ce:9b:6c:48:94:56:a1:fe not verified (check hostfingerprints or web.cace
rts config setting)
pushing to https://the_drow#bitbucket.org/the_drow/agile.crm.framework
pushing subrepo Logging to https://the_drow#bitbucket.org/the_drow/agile.crm.fra
mework/Logging
warning: bitbucket.org certificate with fingerprint 81:2b:08:90:dc:d3:71:ee:e0:7
c:b4:75:ce:9b:6c:48:94:56:a1:fe not verified (check hostfingerprints or web.cace
rts config setting)
abort: HTTP Error 404: NOT FOUND
I have encountered this link that describes how to solve the problem but I don't understand what to do.
Should I place my Logging subrepository in D:\Work\?
What exactly should I do with the mercurial subpaths? Will this enable me to clone locally?
EDIT:
As requested, here are the contents of my .hgsub file
Logging = Logging
As noted in the link that you posted, "You have to make the subrepositories as siblings of the main repository."
So on BitBucket, you need the following structure:
https://bitbucket.org/the_drow/agile.crm.framework
https://bitbucket.org/the_drow/Logging
Then your .hgsub inside agile.crm.framework needs to contain the following:
Logging = ../Logging
I'm going to bump an old question because I think I have a better solution. I understand why #the_drow has issues with the original accepted answer since with Logging = ../Logging your local machine has to have the Logging subrepo as a peer with the containing/master repo. This kind of defeats the purpose of subrepos from an organization point of view. However, if you use the subpaths feature, you can get Mercurial to rewrite the URI for you on push:
external/my_subrepo = external/my_subrepo
[subpaths]
([https://|ssh://hg#])bitbucket\.org/moswald/my_project/external/my_subrepo = \1bitbucket.org/moswald/my_subrepo
Now my local copy of the my_subrepo sub repository is stored inside my_project as expected, but when I push to Bitbucket, it's rerouted to the real thing. In fact, you can use that rewriting feature to point pretty much anywhere since Mercurial understands Git and SVN. I've got more than a few Bitbucket repositories that have subrepos by other authors who use Github.
Related
I want to push a repository from my computer to a repository on a remote site for the purpose of synchronizing the files. TortoiseHg seems to correctly identify outgoing changesets, but when I try to push the changes, TortoiseHg responds with "abort: destination does not support push" with "Push to https://myid:ps#mydomain.com aborted, ret 255" in the status bar at the bottom. The log file includes "(falling back to static-http)"
I've googled but I'm getting nowhere. What does "abort: destination does not support push" mean in English? What doesn't support push? What is the "destination"? Is it the settings in the config files in the repo that make it so the destination doesn't support push? Is it the way the server is set up?
One of the responses to 27967022 "Your destination does not support push, or push is disabled" So how does one enable push?
If you use hgweb on the server side, to allow pushing to a repository, add
[web]
allow_push = *
to its .hg/hgrc on the server or in your hgweb.config. You can also allow pushing only for specific users by listing them instead of *. This is documented here.
If that is not the case and you just use the https server to serve the repo as files, you'll not be able to push via https. In that case, your most likely option is to push via ssh, as in
hg push ssh://myid#mydomain.com/path/to/repo
This requires that you have ssh access to the server and that the repository lies in $HOME/path/to/repo. For an absolute path (if the repository lies in /path/to/repo and not below $HOME), push to ssh://myid#mydomain.com//path/to/repo (note the double slash).
If you always push to the same destination, you can add this path to your local .hg/hgrc:
[paths]
default-push = ssh://myid#mydomain.com/path/to/repo
so that you can then just use hg push.
What are you running for your mercurial server on mydomain.com? If it's hgweb, then #wintermute has your answer. If you're serving static HTTP (using Apache, nginx, etc.) then your server is setup for clone or pull, but not push. More likely you just need to enable push like #wintermute is saying.
I am having a problem to trigger a repository clone of googlecode project.
I keep receiving the following error:
Started by user anonymous $ hg clone
--rev default "https://username#demo.projectname.googlecode.com/hg/ " "F:\Hudson\jobs\project Demostration project\workspace" abort: demo.projectname.googlecode.com certificate error: certificate is for
*.googlecode.com, googlecode.com, *.codespot.com, *.googlesource.com, googlesource.com (use --insecure to connect insecurely) ERROR: Failed to clone.
--template {node}
Anyone know on how to tell jenkins it is safe to use that certificate? In what textbox do you place --insecure option
That's a relatively new command line option (1.8.3 I think) to get around a relatively new practice of actually checking certificates (1.8.2 I think). It's likely not exposed in the Jenkins UI. Some things you could do to work around it:
put the server's cert's fingerprint in a whitelist in your (Jenkin's user's) hgrc
wrap Mercurial in a quick shell script that passes --insecure
clone from the non-https version of the google URL (I think they still allow that)
configure the CACerts for Mercurial either globally (/etc/mercurial/hgrc) or in the Jenkins user's ~/.hgrc
Any of those should work and most of them are explained here: https://www.mercurial-scm.org/wiki/CACertificates
I've got a mercurial repository, which pulls in dependencies using the subrepository functionality (as defined in the .hgsub file), but I'm struggling to get this working in TeamCity.
I've enabled the mercurial_keyring extension in order to save credentials (so when TeamCity provides authentication details for the root repository, it remembers them for the subrepositories). I've added an [auth] section to mercurial.ini too:
[auth]
bitbucket.schemes = https
bitbucket.prefix = https://bitbucket.org/xyz
bitbucket.username = xyz
If I run hg clone from the command line, I get prompted for a password once, and all is good. But the initial checkout when run via TeamCity fails with
VCS root: mercurial: https://bitbucket.org/xyz/projectA {instance id=23, parent id=1}, due to error: 'cmd /c hg update -C -r 4a08f587bb1f' command failed. stderr: abort: http authorization required stdout: pulling subrepo src\Common.Library from https://bitbucket.org/xyz/common.library
What am I missing, or am I going about this in completely the wrong way? Many thanks!
It seems that passing in credentials directly from TeamCity doesn't work with mercurial_keyring, but if I specify both username and password in plaintext in the mercurial.ini file (making sure it's accessible under the account the TeamCity build agent is running under), then this works.
The mercurial.ini file can be placed under <mercurial install path>\mercurial.ini if it does not work under user path.
Not ideal, but a solution... if anyone else finds a better one, please let me know.
May be it got fixed in last versions of TeamCity, but the following works for me:
Configure build agent service to run under domain account with
access to HG repositories (both root and subrepos)
Enable mercurial_keyring on build agent and add [auth] section
to mercurial config
Try to clone repository manually, enter
password. No need to wait until the whole repo is cloned -- it could
be terminated when "requesting all changes" message is shown.
Have fun -- now service will use keyring.
Probably the [auth] section shouldn't be added at all to the mercurial.ini for the TC agent. Team City uses --config auth... options to hg. I would also recommend not to use the mercurial_keyring but to set the username and password in VCS root - this is both secure and shared between different TC agents.
Not sure about the bitbucket, but in other cases usage of https scheme can require certificates configuration. This can be configured in mercurial.ini:
[web]
cacerts =
[hostfingerprints]
# hides mercurial warnings
domain-name = ab:cd:...:01
And last part: depending on .hgsub it might be needed to use VCS checkout mode "Automatically on agent" in Team City Version Control Settings.
UPDATE - I'm probably being daft, see my last update below.
I just did a hg push and it timed out, and now when I try hg push again I get a message 'no changes found', however I can see in the target repo that all but a few of the changes didn't make it to the repo. How can I push my changes to that repo?
The history behind this is I'm migrating from SVN to Mercurial (bitbucket). I've done the following:
Used svnsync to get a local copy of the SVN repository.
Created a new repo within bitbucket
Cloned the repo to my local machine
Done svnadmin convert from my local SVN repo to my local Hg repo
Run hg push to push the changes to bitbucket
The last command prompts me for HTTP authorisation, then says 'searching for changes', no output for >15 mins, then output 'abort: HTTP Error 504: Gateway Time-out'. Full process was:
C:\dev\sandbox\svn_to_hg\dev_hg>hg push
http authorization required
realm: Bitbucket.org HTTP
user: my_login
password:
pushing to https://bitbucket.org/my_login/dev
searching for changes
abort: HTTP Error 504: Gateway Time-out
C:\dev\sandbox\svn_to_hg\dev_hg>hg push
http authorization required
realm: Bitbucket.org HTTP
user: my_login
password:
pushing to https://bitbucket.org/my_login/dev
searching for changes
no changes found
It seems that because there are so many changes it's taking too long between HTTP auth and when it actually pushes the changes, or something like that, and probably if I set up SSH keys it'd not need to cache the HTTP authentication so it wouldn't time out. Any ideas if that's correct? Regardless, I still need to know how to push these changes that hg now thinks have already been pushed.
In my bitbucket repository there are about 20 changesets from SVN from a few years ago, but there should be several thousand.
UPDATE:
hg out gives me this:
C:\dev\sandbox\svn_to_hg\dev_hg>hg out
http authorization required
realm: Bitbucket.org HTTP
user: my_login
password:
comparing with https://bitbucket.org/my_login/dev
searching for changes
no changes found
Looking at the repo using TortoiseHg repo browser shows there is tons of stuff there.
UPDATE:
Perhaps I'm being daft, now when I look at the repo within bitbucket it does seem that there are lots of changesets. But what timed out? Should I worry that all my changesets didn't make it to the server?
It seems that all changesets did make it - i.e. answer is to retry and then trust Mercurial.
Before explaining my problem let me tell you the Mercurial setup,
We have the following repos,
RELEASE
DEVELOPMENT
BUGFIX
All the above repo are running on a central server using IIS and hgwebdir.cgi
Now coming to the problem,
I clone a local repo from DEVELOPMENT repo.
I make changes to the clone and commit (Not push).
I make a bundle from the clone and pass the bundle to QA who has cloned the RELEASE repo.
Now I try to apply the bundle to the RELEASE repo clone using hg unbundle
I get an error, abort: error: ftp error: no host given
What am I doing wrong? Can you give solution to the above problem keeping a Windows setup in mind?
It really sounds like you have a syntax error in your unbundle command. The normal usage is just:
hg unbundle c:\path\to\the.bundle
there's no ftp involved unless you're trying to use a ftp:// URL which isn't supported. Is it possible you have a directory named ftp and the parser is mistakign it for a component in a ftp URL?
Also, most folks wouldn't use bundles in the scenario you're describing. They'd just do:
hg push URL-or-file-path-to-QA
and push direct to QA's own repo (not to RELEASE)
People generally use bundles only when a network connection isn't possible or practical.
I experienced the same problem, I don't think hg likes uncs.
I mapped \server\DevSourceCode\Mercurial to R: and it worked fine, see below:
R:\Repositories\myproj>hg unbundle \\server\DevSourceCode\Mercurial\ChangeBundles\myproj_changes.hg
abort: error: ftp error: no host given
R:\Repositories\myproj>hg unbundle R:\ChangeBundles\myproj_changes.hg
adding changesets
adding manifests
adding file changes
added 0 changesets with 0 changes to 139 files
(run 'hg update' to get a working copy)