I am using windows explorer to clone a repository from a folder in a mapped drive into my local working folder. I have never encountered this problem before with any of my previous repositories, but I keep getting an error while the directory is cloned. The error points to a file that is of "unkown format". This is the exact error:
abort: index data/Scripts/tiny_mce/themes/advanced/skins/default/dialog.css.i unknown format 5661!
About half of the repository gets cloned, but it never finishes because of that error half way through. I have used a remote command that supposedly skips over unknown formats (I found it somewhere online), but it doesn't work. This would be the complete command:
hg clone --remotecmd skip-unknown-format --verbose -- Q:\mercurial-repository\east C:\working
Any pointers on how I can skip that one file and/or how I can fix this error?
This is my hg version info:
version 2.4
with Mercurial-2.2.1, Python-2.6.6, PyQt-4.8.6, Qt-4.7.4
Related
Today I was trying to integrate from a child streamC to a parent streamP (copy-up operation) in Perforce. This operation is performed almost every day and usually we don't experience any issues. But today something went wrong. On a few files Perforce throws an error:
Operation 'rmt-FileFetch' failed.
Librarian checkout /opt/perforce/..../fileA
Error opening librarian file /opt/perforce/..../fileA revision 1.2555519.
RCS checkout 1.2555519 failed!
RCS no such revision 1.2555519!
And the same error is shown on a few other files.
I've checked status of these files in a parent stream streamP and they are all marked for delete by somebody else.
Is it a bug in perforce that you cannot integrate file deletion if it is already marked for delete?
Or is it a perforce infrastructure issue and I need to talk to IT guys?
If the file is deleted in the source there shouldn't be a librarian operation at all. Sounds a lot like this (fixed) bug:
Bugs fixed in 2016.1
#1378013 (Bug #85458) **
'p4 copy' could produce a librarian error when attempting to copy
a source file that was moved and then deleted. Fixed.
https://www.perforce.com/perforce/doc.current/user/relnotes.txt
I'm trying to clone a Mercurial repository hosted on BitBucket via SSH from the Windows command line.
When I add the --debug flag I can see that it never gets past the 'sending between command'
When I ctrl+c, it just shows interrupted! without any other error messages.
I'm also looking at the Resource Monitor and it's not showing any related network traffic after the first minute or so.
I have tried adding the --noupdate option and the --uncompressed option with the same results.
Windows Server 2012 with just Mercurial - No TortoiseHg
Any ideas?
Is there a reason the 'sending between command' would take awhile? The repository is about 150MB
I know I'm late to the party, since Bitbucket has long dropped the Mercurial support, still this might be relevant to those setting it up on Windows to use with any other service or in a self-hosted environment.
I assume that you've set plink as your SSH client. If not, this can be easily done by adding the ssh parameter in your Mercurial configuration. Here is what my mercurial.ini file's contents look like:
>hg config --edit
[ui]
ssh="C:\programs\putty\plink.exe" -ssh -2
I spent like two hours tinkering around with my setup before I had an Aha! moment and tried to connect to the server with plink to see if the problem lies there:
>plink.exe hg-ssh#hg.example.com -noagent id
The server's host key is not cached in the registry. You
have no guarantee that the server is the computer you
think it is.
The server's ssh-ed25519 key fingerprint is:
ssh-ed25519 255 90:8d:b0:26:c5:6e:74:2a:6c:3d:80:42:54:9e:15:47
If you trust this host, enter "y" to add the key to
PuTTY's cache and carry on connecting.
If you want to carry on connecting just once, without
adding the key to the cache, enter "n".
If you do not trust this host, press Return to abandon the
connection.
Store key in cache? (y/n)
Bingo!
As you can see here, plink prompts for the input, and we have to provide it before it can proceed any further. So this is what makes hg hang indefinitely if we don't.
You can also download Process Explorer, open it and choose Show Process Tree (Ctrl+T) from the View menu, and search for the process plink. You can see that this process is running and is a child of hg.
I answered "y", and the key was cached in a registry entry under the
Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys
The new entry contains the remote server name and the key itself.
Once that was out of the way, I could go about my business using clone, push, pull, as well as other commands, like in and out:
>hg clone ssh://hg-ssh#hg.example.com/review
destination directory: review
requesting all changes
adding changesets
adding manifests
adding file changes
added 2 changesets with 4 changes to 4 files
new changesets f82779871203:e9b1a2b79f98 (1 drafts)
updating to branch default
4 files updated, 0 files merged, 0 files removed, 0 files unresolved
It looks like hg messes with the input and the output of the SSH client, and you never get to see what is going on there, nor can you interact with it. And specifying the --debug option makes no difference.
You can also supply the -sshlog option to plink to save the log protocol details of a session to a file:
[ui]
ssh="C:\programs\putty\plink.exe" -ssh -2 -sshlog plink.log
Here is a portion of the log, where it says that a host key is unknown to the client:
Incoming packet #0x2, type 21 / 0x15 (SSH2_MSG_NEWKEYS)
Event Log: Server also has ecdsa-sha2-nistp256/ssh-rsa host keys,
but we don't know any of them
Event Log: Host key fingerprint is:
Event Log: ssh-ed25519 255 90:8d:b0:26:c5:6e:74:2a:6c:3d:80:42:54:9e:15:47
And it is getting stuck around that spot waiting for the user input.
Out of curiosity I downloaded the Mercurial source code and tracked the debug messages down to the method _performhandshake in hg/mercurial/sshpeer.py:
$ hg clone https://www.mercurial-scm.org/repo/hg
$ grep -R 'sending between command' hg
$ less hg/mercurial/sshpeer.py
ui.debug(b'sending hello command\n')
ui.debug(b'sending between command\n')
Full sshpeer.py source code.
You can see up the call stack there's a call inside the instance to the _makeconnection, which in turn calls the procutil.popen4, which then uses subprocess.Popen class constructor to spawn a new process, and subprocess.PIPE is used as a value of the stdin, stdout, and stderr arguments.
And from the subprocess manual, you can see that:
PIPE indicates that a new pipe to the child should be created.
So this pretty much explains why you cannot interact with the SSH client, as all its standard input, standard output, and standard error are eaten up by Mercurial.
Anyone reading this answer, give this solution a try, and let us know if it was helpful!
Today i've tried to push changes into our shared repository hosted on an apache(2.2.x) running webdav(over HTTPS).
The repository in the dav-directory is a clone of my working directory. Option NoUpdate is enabled. Both Repositories are initiated.
To move on I mapped the dav-directory/repositoy as network drive and set the repository to push to "y:/"
When I try to push from Workbench the exception "aborted, ret 255" is thrown.
% hg --repository C:\wamp\www\ommon push y:
pushing to y:
searching for changes
abort: Y:\.hg/store/journal: The system cannot find the file specified
[command returned code 255 Thu Jun 20 12:08:28 2013]
Pushing from commandline throws:
pushing to y:\
searching for changes
abort: y:\.hg/store/journal: The system cannot find the file specified
Exception AttributeError: "'transaction' object has no attribute 'file'" in
<bound method transaction.__del__ of <mercurial.transaction.transaction object>>
I tried to alter the path to directory since the side-swapped dividers are looking strange to me. But it did not succeed.
Further information: I'm not using hgweb or any cgi-script based version.
EDIT Multiple google entries in reference to the issue left me with the idea that pushing changes to a repository provided by webDAV is not entirely possible. Further I have to use hgWeb to resolve that.
But why do I have to? My idea is that webDAV is capable of writing. Since i mapped the directory as a network drive - mercurial should be able to push changes on to the webserver likewise it does to a local directory.
Can someone confirm this?
Windows WebDAV support can be shaky. It's very possible that because of mercurial's likely advanced file-system operations, the OS does something incorrectly, or something apache's mod_dav cannot cope with.
It's also possible that something simpler is wrong, like apache blocking access to paths starting with a ..
You may be able to find something in your apache log, but I would recommend not doing this and use a true mercurial server instead.
Mercurial's http-repositories NEVER speak on WebDAV
You have to use any Mercurial-capable web-frontend for communication with repo or mount WebDAV-drive as local drive and access repository on it as repository on local FS
Basically, this is the log I get:
Started by user dontcare4free
$ hg clone --rev default ssh://hg#bitbucket.org/dontcare4free/my-repository /var/lib/jenkins/workspace/Custom-MC-Server
* failed to import extension hgext.imerge: No module named imerge
remote: Host key verification failed.
abort: no suitable response from remote hg!
ERROR: Failed to clone ssh://hg#bitbucket.org/dontcare4free/my-repository
[Custom-MC-Server] $ hg log --rev . --template {node}
java.io.IOException: Cannot run program "hg" (in directory "/var/lib/jenkins/workspace/My-Repository"): java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:475)
at hudson.Proc$LocalProc.(Proc.java:244)
at hudson.Proc$LocalProc.(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:698)
at hudson.Launcher$ProcStarter.start(Launcher.java:329)
at hudson.Launcher$ProcStarter.join(Launcher.java:336)
at hudson.plugins.mercurial.MercurialSCM.joinWithPossibleTimeout(MercurialSCM.java:299)
at hudson.plugins.mercurial.HgExe.popen(HgExe.java:191)
at hudson.plugins.mercurial.HgExe.tip(HgExe.java:171)
at >hudson.plugins.mercurial.MercurialSCM.calcRevisionsFromBuild(MercurialSCM.java:255)
at hudson.scm.SCM._calcRevisionsFromBuild(SCM.java:304)
at hudson.model.AbstractProject.calcPollingBaseline(AbstractProject.java:1205)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1194)
at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:555)
at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:443)
at hudson.model.Run.run(Run.java:1376)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:175)
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.(UNIXProcess.java:164)
at java.lang.ProcessImpl.start(ProcessImpl.java:81)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:468)
... 18 more
Jabber notifier plugin: Sending notification to: -snip-
Jabber notifier plugin: Notifying suspects
Jabber notifier plugin: Notifying culprits
Notifying upstream projects of job completion
Finished: FAILURE
As far as I can see this means that it can't find the hg executable. However, I get no such errors when I try executing hg as a build step (shell execute) with Mercurial integration disabled.
I've tried with and without changing installation directory and executable and I've even tried compiling (well, whatever of that there is) Mercurial manually from source, all to no avail.
EDIT: Silly me. I completely misread the log. The issue is not related to it not finding the hg executable at all, but it's actually because I forgot to set up my key properly.
Inspecting http://localhost:8080/systemInfo Environment Variables > PATH displays "/usr/bin:/bin:/usr/sbin:/sbin". I can't determine why this is all that Jenkins sees. When logging in as the daemon configured user, I get a much larger set of paths.
I was able to help the Mercurial Plug-in find "hg" by creating a symlink to hg.
sudo ln -s /usr/local/bin/hg /usr/bin/hg
I tried adding the following to /etc/profile (I restarted just in case)
PATH=$PATH:/usr/local/bin
export PATH
I verified that this modified my path by typing
echo $PATH
in Terminal. However, this path did not show up in Jenkins
I am able to work with the sym link solution but I'd really like to understand where Jenkins gets its Path.
Nullable is right, the issue isn't that the hg executable can't be found, but rather that the jenkins user doesn't have a public key.
The solution is as follows:
Log in as the jenkins user
Make sure the jenkins user has a public ssh key, which should be in .ssh/id_rsa.pub
If not, generate one using ssh-keygen and don't specify a passphrase
Issue cat .ssh/id_rsa.pub, copy the output.
Log into bitbucket or github, add the public key you just copied into your account
Try again!
Hope that helps, best of luck to anyone with this issue.
My first thought would be that you should check the path to the hg executable in jenkins set up, if there is such an option, it may not point to the correct path.
If that doesn't help, make sure hg is on the PATH.
Looks like there might be some set up required according to this page http://www.pixelastic.com/blog/162:failed-to-import-extension-hgext-imerge-warning-on-dreamhost
Maybe that can fix your issue?
I am trying to use the "Perfarce" extension to Mercurial to create an hg repository (working copy) that is managed by mercurial, with a link to check out and in to a central perforce server "depot".
The help says to enter a command like this:
hg clone p4://hostname:portnumber/userid
When I do this, it creates a folder under my current working directory named with the userid name (so it seems sub-optimal way to pass the user name to the p4 url), and I get this error:
abort: p4: ... - must create client 'userid' to access local files.
The second try fails with destination is not empty error.
I have also tried specifying a destination:
hg clone p4://hostname:portnumber/userid dest
This doesn't work either -- same error message about creating a client. I don't see a way to tell it about my WORKSPACE, if any, or which depot, on the particular hostname to check out.
I already having a WORKSPACE that p4 and p4v know about, and it's in a different folder than the place where I would like to have my hg+perfarce working copy. I suspect the p4 command line program might be confused by this.
Has anyone gotten the "perfarce" extension working with mercurial? What did you do exactly, and what am I doing wrong, and not understanding?
You must have a Perforce client created when using Perfarce. You then use the specified convention to access the perforce depot. As per Perfarce documentation
hg clone [--startrev REV] [-r REV] [p4://server/clientname] [dest]
Also, make sure you have the destination folder created on your machine. It must be the same as set in the client. If your client spec specifies d:\foo you must run the Perfarce command in d:\ and have an empty foo directory. Not using the optional dest Perfarce creates a directory using the client name.
If your Perforce client is using the default settings and using the read-only flag, you might want to use the MakeWriteable extension.
It looks like you have to type "p4 client", and then edit the resulting file which sets up access to various depots within the p4 server. Then the hg commands will work in this working folder.
Except that it dies with an abort, from p4 client run within the hg clone operation, with a missing file error, each time a different missing file.
I'm new to Perfarce, too, but I've found that I need to use p4 login, even though this is not otherwise required by my P4 server. Perfarce doesn't seem to recognize P4 settings files set up via P4CONFIG.