Trying to push to a Kiln repo. There are definitely changes, lots of them, hg status lists 238 files changed. There is a warning that the certificate with fingerprint blah blah is not verified -- though if it's just a warning why would it interfere with the push?
Full output:
pushing to https://mydomain/Code/Repositories/Group/myrepo
warning: mydomain certificate with fingerprint fe:ab:65:89:7c:6f:1a:21:a8:39:54:6c:2a:cb:ca:ae:e9:e5:f0:01 not verified (check hostfingerprints or web.cacerts config setting)
warning: developers.kilnhg.com certificate with fingerprint fe:ab:65:89:7c:6f:1a:21:a8:39:54:6c:2a:cb:ca:ae:e9:e5:f0:01 not verified (check hostfingerprints or web.cacerts config setting)
searching for changes
searching for changes
no changes found
Googling this has turned up nothing.
You need to commit your changes to the local repository before you can push the resulting changeset to a remote repository. Use the command hg commit to do so.
Related
We discovered that our Hg repository got corrupted several weeks ago. This corruption seems to have propagated: all clones (the central repo and the user repos) are corrupted, pretty badly, in the same way. I think we could have prevented it if we did verification at that time.
Is there some Hg setting that would cause verification on each push, and prevent push in case of verification failure? I know I could implement it as a hook in Python, but is there maybe a simpler solution?
Is it also possible to do the opposite: make sure the remote repository is verified before pulling?
FWIW, I am on Windows 10 and we are using TortoiseHg.
Update: I've tried creating hooks as suggested by Jordi. Hg now hangs waiting for locks. Here is what I see:
c:\Users\username\test-hook>hg init
c:\Users\username\test-hook>cd ..
c:\Users\username>hg clone test-hook test-hook-clone
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
# At this point I edited clone repository settings to include
# [hooks]
# preoutgoing = hg verify
#
# Then I created a test.txt file and "added" it via TortoiseHg context menu.
c:\Users\username\test-hook-clone>hg commit
c:\Users\username\test-hook-clone>hg status
c:\Users\username\test-hook-clone>hg outgoing
comparing with c:\Users\username\test-hook
searching for changes
changeset: 0:a61d33af6cdb
tag: tip
user: username
date: Mon May 06 20:32:54 2019 +0200
summary: test file added
c:\Users\username\test-hook-clone>hg push -verbose
pushing to c:\Users\username\test-hook
searching for changes
running hook preoutgoing: hg verify
waiting for lock on repository c:\Users\username\test-hook-clone held by process '16840' on host 'LT407233'
To answer your question, the hook does not have to be written in Python. In the appropriate server's hgrc (either at the repository level or the system level), simply set
[hooks]
preoutgoing = hg verify
preincoming = hg verify
This may significantly slow down all pull and push operations, but perhaps you are willing to sacrifice speed for correctness.
This will result in output like this when a client tries to pull from a corrupt repo:
$ hg clone http://localhost:9000 sample-repo
requesting all changes
remote: abort: preoutgoing hook exited with status 1
and in your server logs, you should see output similar to
127.0.0.1 - - [18/Apr/2019 12:41:09] "GET /?cmd=batch HTTP/1.1" 200 - x-hgarg-1:cmds=lheads+%3Bknown+nodes%3D x-hgproto-1:0.1 0.2 comp=zstd,zlib,none,bzip2 partial-pull
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
a#0: broken revlog! (index data/a.i is corrupted)
warning: orphan data file 'data/a.i'
checked 2 changesets with 1 changes to 2 files
1 warnings encountered!
1 integrity errors encountered!
(first damaged changeset appears to be 0)
You can enable a server side option to perform more validation all incoming content, just set the server.validate=yes option on your server.
The simplest way is to enable it in your server global hgrc or in the repository .hg/hgrc file by adding the following two lines:
[server]
validate = yes
This is a server option but you can also use it on the client. It should validate pull too.
(By the way, what kind of corruption are you seeing?)
I've some code on my laptop I would like to upload through Mercurial on my BitBucket repository.
I'm using a Linux CentOS 6 machine.
The problem is that if I type $hg push, I get the following error message:
pushing to default-push
abort: repository default-push not found!
What should I do?
Thanks
Mercurial doesn't know where you want to push to. Mercurial first looks for the destination in the push command (which could be either a repo on the filesystem, or a remote hg server):
hg push remoterepo
If it doesn't find a destination in the command, it will fall back on the defaults.
Normally, assuming this repository was cloned, the hgrc file (in .hg/) will indicate the default repository to be used.
However this assumes that the repository was created by cloning an existing repo.
If not, you can edit .hg\hgrc and add the default destination eg:
[paths]
default-push=http://yourserver/
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.
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.
Windows XP, Mercurial 1.6.4
hg clone https://demas#bitbucket.org/demas/start.here
destination directory: start.here
requesting all changes
abort: error:
But if I use SSH all works fine
hg clone ssh://hg#bitbucket.org/demas/start.here
Debug info:
hg clone --debug https://demas#bitbucket.org/demas/start.here
using https://bitbucket.org/demas/start.here
http auth: user demas, password not set
sending between command
destination directory: start.here
sending heads command
requesting all changes
sending changegroup command
abort: error:
Why? And how I fix it?
Use a custom configuration to workaround the handling of self-signed certificates:
Note that per the default settings installed, connect to repositories with self-signed certificates fail with 1.7.3. You need to adjust the default configuration for that case.
References
CA Certificates in hg on Windows
hg import from a https URL fails