Google Code changing host fingerprint causes hg pull to fail - mercurial

I'm using Google code and Mercurial for a small project javaclass-rb. I cloned the repository using HTTPS. My .hg/hgrc contains
[paths]
default = https://javaclass-rb.googlecode.com/hg/
From time to time Google Code has a different fingerprint (most likely to the clustering of service). When I want to pull (with hg 1.8.4), I get
E:\Develop\JavaClass>hg pull -u
abort: invalid certificate for javaclass-rb.googlecode.com with fingerprint 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then I have to change my ~/.hgrc file and update the hostfingerprintssection to contain the new fingerprint:
[hostfingerprints]
javaclass-rb.googlecode.com = 28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Then everything works fine again, until next time. Now this gets annoying as I did it ten times already, approx. once a month, and have to do it on several machines (desktop, laptop, work pc etc.)...
34:4b:90:e7:e3:36:81:0d:52:1f:10:c0:4c:98:66:90:4a:9e:05:c9
6e:a8:09:6a:42:60:d7:81:f7:04:b8:0f:5d:1e:ac:b3:58:db:7e:da
89:6d:fb:e5:4a:7e:72:91:db:0b:ee:72:9f:60:a7:29:65:fd:e1:10
da:b3:df:aa:55:73:ac:65:04:70:78:8e:ed:dd:a9:be:40:a8:64:81
a9:be:c0:4a:da:1c:eb:4c:31:9d:78:27:48:99:f4:9c:9a:e8:53:c8
ed:19:7c:b9:a3:48:27:93:72:74:43:db:26:40:af:e0:7a:90:1c:97
28:92:6b:9b:40:10:cc:0e:4c:16:a4:78:7f:bb:1a:8d:d4:d1:d3:27
Do you know a way to configure Mercurial to ignore the fingerprints or some other way I get rid of this annoyance?
Answer
tonfa led me on the right track. Mercurial is checking also OS certificates. Originally I had to fall back to fingerprints because Googlecode certiicate is not valid for subdomains:
The certificate is only valid for the following names:
*.googlecode.com , *.u.googlecode.com , googlecode.com , *.codespot.com , *.googlesource.com , googlesource.com
1) I removed the fingerprints from .hgrc, then the top domain javaclass-rb.googlecode.com worked again, because it is matched by *.googlecode.com.
2) Subdomains have to be cloned with another name, see Google support.

Ignoring the fingerprints and not verifying the signature is a very bad idea.
You should follow the instructions at https://www.mercurial-scm.org/wiki/CACertificates (basically a recent version of TortoiseHg should be already correctly configured).

Try the command hg pull --insecure.

Related

Gerrit review not found in spite of present in DB

We are using Gerrit 2.12 with MySQL DB. There is one review open for a while but when I try to access it from Gerrit UI, I get following error.
The page you requested was not found, or you do not have permission to view this page.
I am logged into the UI and my account have administrative capabilities.I can see the entry of the change in changes table in data base. Should reindexing solve the problem? I am more curious about what was the trigger for disappearance of change in UI.
I had the same problem. I have verified if the changes were there in the repository by cloning the corresponding change under refs/changes branch.
As the documentation says, When a commit is pushed for review, Gerrit stores it in a staging area which is a branch in the special refs/changes/ namespace. A change ref has the format refs/changes/XX/YYYY/ZZ where YYYY is the numeric change number, ZZ is the patch set number and XX is the last two digits of the numeric change number, e.g. refs/changes/20/884120/1. Understanding the format of this ref is not required for working with Gerrit.
Using the change ref, git clients can fetch the corresponding commit, e.g. for local verification.
git clone <URL>
cd <reponame>
git fetch https://yourhostname/reponame refs/changes/16/261016/1 && git checkout FETCH_HEAD
If you find the fetch to be happening successful, it means that the change is present and therefore a full reindex as the appropriate user should fix.
su gerrit -c "java -jar gerrit.war reindex"
PS. Online reindex did not help in my case. I had to do a full offline reindex as above.

Binary equal files show as modified, unable to revert

I suddenly have a few files that show as modified, but KDiff says they are binary equal. Reverting and discarding those changes does nothing.
Somehow, the eol extension is enabled and when I try to disable it, I can't view that one repo's Working Directory in TortoiseHg. An error appears:
[Error 6] The handle is invalid
When using the command line hg status, this error appears:
'cleverencode:' is not recognized as an internal or external command,
operable program or batch file.
When using hg revert myfile, .orig files are generated but the files still appear as modified and the same error from above appears.
When updating to a previous commit, a whole lot of other files get in the same situation like those few I have now.
If necessary, I can throw away this clone and make a new clone, but it would be nice if this can be resolved without doing so.
Was able to solve it.
My global mercurial.ini had some lines with cleverencode in them. After removing those, the issue has disappeared. Enabling/disabling the eol extension also doesn't seem to cause any issues any more.
I suspect the troublemaker was Atlassian's SourceTree, I had installed an update yesterday and it asked if automatic line ending handling should be enabled. I'm quite sure I unchecked it, regardless, it seems to have mixed eol config with win32text config.
See also: [SRCTREEWIN-708] Possible error with Mercurial line ending handling configuration - Atlassian JIRA
I found that the cleverencode did not work for me -- I didn't have it in my mercurial.ini. My case was also a binary file that mysteriously got marked as modified and would not go away with revert, clean, etc...
I did some poking around and fixed it: there's a repo/.hg/largefiles directory. I believe mercurial keeps this as a local cache of binary files in order to revert back changes. In this directory you'll see a bunch of file names in hex. In TortoiseHg "browse" your binary file causing the problem. It'll show you the hex code corresponding to your binary. Find that file in the largefiles directory and delete it.
You should now be able to revert the file back to unchanged. I think mercurial uses the largefiles version to revert first. Then, when this version doesn't match the repo version it gets marked as modified (in my case my binary somehow got truncated to 0 length) and will never go away.
You can also just delete the largefiles dir altogether if you can't match the hex name. It will get recreated as needed. I think the only repercussion is that it's take longer to do some binary file operations since it will have to go to the server.

Is there a way to email regular, aggregated mercurial changesets reports?

In an effort to boost code reviews, I am looking to send a daily/weekly/monthly/some_regular_interval report of changes from mercurial? I figure that if a person does not have to go and find the changes, but they are instead brought to the person, then that should be a step in the right direction. However, I did not see anything already out there. (We use mercurial with TortoiseHG and Jenkins for the automated build in case any of those tools might help?)
What I am looking for:
MUST HAVE
commit message
list of files that changed
NICE TO HAVE
changeset guid
name of person who did the commit
some means to see what changed on each file (probably best via a URL or else the email could become overloaded)
You don't state what OS you are using. I am assuming Windows since you are using TortoiseHG.
On Linux (or other UNIX-based OS) you can create a cron that runs once a week/month/whatever. The following simple script satisfies most of your requirements on my Linux machine:
LOG_DATE=`date -d "1 week ago" +"%Y-%m-%d 00:00:00"`
hg log -d ">$LOG_DATE"
If you use Mercurial templates you can get exactly what you want. You can construct a URL using the changeset ID to point to a Mercurial web-server.
Would the notify extension work? You can configure this on a designated master repository so that emails with a summary of the changes (you can customise the template to include the short form of the hash, the user name, the commit message) along with URLs to the individual changesets are sent out to people whenever changese are pushed to the master repository.

Mercurial's authors description

I'm trying to change Mercurial's template.
When I push some files to my repository, the log files list my PC's name, not user's name that is logged in.
I don't want the PC's name, I want logged user's name shows up.
How I do it?
#Praveen-K has the right answer and Lazy Badger and Lasse have the details you're missing. Here it is spelled out, but go pick Praveen's answer:
The user name you're seeing in/on your remote repository are completely unrelated to:
Any settings on your repository/server
The username you use to authenticate to your repository
Instead that string, called 'author' is burned into the changeset (commit) at commit time and is entirely crafted on your "PC". You could set it to anything you want and once you push that commit to the repository that's how it will display.
At your current skill level you're not going to successfully change that string in commits you've already made, but if you dive into a good explanation (not lookup commands) like the hg book you'll come away understanding things.
Make the entry in to your hgrc file. This file should be in your .hg/ directory (it may be in your repo or you can do in your home directory) and if it is not exist make the file with the name of hgrc in that folder.
[ui]
username = Your Name <your#mail>

Mirgrating from mercurial Bfiles to largefiles

I have used mercurial's bfiles extension for some time and it works fine. The only problems are installation and the special "hg bfadd" command.
Now that Mercurial 2.0 include the largefile extension I would like to switch.
Can't find any tools or guides on how to do it? Anyone tried it yet.
I have several repositories that all use the same store and have the following mercurial.ini.
[bfiles]
store=\\Someserver\Mercurial\bFilesStore
autostatus = true
autoupdate = true
autorefresh = true
autoput = *
You can find the documentation here : https://www.mercurial-scm.org/wiki/LargefilesExtension
To enable the extension add the following to your hgrc :
[extensions]
largefiles =
You can add a new large file with :
hg add --large thisfileislarge
About the migration, the readme.txt of the bfiles extension says something about a migrate.txt file ( https://bitbucket.org/gward/hg-bfiles/overview section "The future"). But I can't find the file anywhere on the repository, maybe he forgot to upload it.
There's also a mail on mercurial-devel about this : https://www.mercurial-scm.org/pipermail/mercurial-devel/2011-October/035161.html but nothing since then.
Maybe the better solution is to contact the author of bfiles about his status on the migration process and keep using the old extension until you have an answer ?
Either way, there's a lot of bug report about largefiles since the release of 2.0, so it's maybe a good idea to wait anyway :)
In the latest hg-bfiles version (from 2011-12-05), if you update to the migrate branch, you get this help file:
bfiles: migrating to largefiles
If you want to migrate from bfiles to the new largefiles extension in
Mercurial 2.0, you first have to decide: convert your repo or keep it?
Converting your repo
This is appropriate if:
you have a small repository
you know exactly where every clone of it is
you can replace every clone
It involves creating an new repo with .hgbfiles/ replaced by .hglf/.
This means that your changeset IDs will differ, so you cannot
pull/push between the old and new repos. You must replace every
existing clone with a clone of the converted repo.
The advantage of converting your repo is that you can say goodbye
forever to bfiles, and move into the future using largefiles alone.
The process is mostly automated by two shell scripts: convert-repo and
convert-store.
Use the convert-repo shell script to convert the repository itself. This is just a wrapper around "hg convert" that takes care
of all the fussy details needed to turn .hgbfiles/ into .hglf/.
It's easy to run:
./convert-repo SRC-REPO DST-REPO
The resulting DST-REPO is not yet ready to use: you still have
to convert the bfiles store to a largefiles store.
Use convert-store to turn the bfiles store into a largefiles store. You must have a local copy of the bfiles store -- so you
probably want to run this on the server where your bfiles store
lives. Again, it's easy:
./convert-store SRC-STORE DST-REPO/.hg/largefiles
Putting the store inside your DST-REPO is the easiest way to
make largefiles just work.
Keeping your repo
(Yes, that's the end of the file, there's no help on how to keep your repository)