Abort with no message while doing hg clone - mercurial

We are using mercural-server for the central repository on a server and windows developers use TortoiseHg as a client. One of developers can't even clone the repository -- hg responses with "abort:" with no message.
SSH authorization is passed successfully -- using the same key on other computer is OK and i can clone the repository and make changes in it.
If i run hg --traceback clone <...> on that developer's computer i get:
Traceback (most recent call last):
File "mercurial\dispatch.pyo", line 88, in _runcatch
File "mercurial\dispatch.pyo", line 743, in _dispatch
File "mercurial\dispatch.pyo", line 514, in runcommand
File "mercurial\dispatch.pyo", line 833, in _runcommand
File "mercurial\dispatch.pyo", line 804, in checkargs
File "mercurial\dispatch.pyo", line 740, in <lambda>
File "mercurial\util.pyo", line 475, in check
File "mercurial\commands.pyo", line 1234, in clone
File "mercurial\hg.pyo", line 267, in clone
File "mercurial\hg.pyo", line 121, in peer
File "mercurial\hg.pyo", line 101, in _peerorrepo
File "mercurial\sshpeer.pyo", line 59, in __init__
File "mercurial\sshpeer.pyo", line 73, in validate_repo
File "mercurial\util.pyo", line 137, in popen3
File "subprocess.pyo", line 679, in __init__
File "subprocess.pyo", line 896, in _execute_child
WindowsError: [Error 2]
abort:
The destination folder is writable. I don't even know what can be a source of a problem, because the same version of TortoiseHg (TortoiseHg 2.7.1 (with Mercurial 2.5.2)) on other windows computer and with the same repository works fine.

In this situation, you should go to the source - hg clone https://www.mercurial-scm.org/repo/hg. Looking at sshpeer.py line 73 and the context around it, it appears the error is occurring when trying to execute the ssh call.
The most likely causes are:
The developer has a messed-up ui.ssh entry in an hgrc somewhere. Possibly they've specified like:
[ui]
ssh = "ssh -C"
instead of:
[ui]
ssh = ssh -C
The developer may have specified a ui.ssh section without having appropriate ssh binaries available. By default, TortoiseHg will use PuTTY (it installs the binaries) but Mercurial will obey if you say to use something else.
If checking the above doesn't help, clone the mercurial source, modify it to display the ssh command (sshpeer ~line 73) and install it in pure mode, then try to clone. This will tell you exactly what is being called.
hg clone https://www.mercurial-scm.org/repo/hg
cd hg
<path\to\python>\python setup.py --pure install
cd <other directory>
<path\to\python>\Scripts\hg.bat clone <repo>
Also, please raise a bug report at the appropriate bug tracker.

Related

PyCharm or Mercurial error: Number of lines annotated by Mercurial is not equal to number of lines in the file

When I click on Annotate, I often get this message in PyCharm 2018.2.5 (running on Ubuntu 18.04):
Number of lines annotated by Mercurial is not equal to number of lines
in the file. Check file econding and line separators
It looks like a Mercurial error, but in command line, the following command on the same file is succesful:
# hg annotate -ud <file>
Line enconding is LF, File encoding is UTF-8
EDIT
Mercurial version:
# hg --version
Mercurial Distributed SCM (version 4.5.3)
The file I'm try to annotate is in a subrepository, and checking the logs I discovered
PyCharm is trying to annotate using the father's repo.
If I execute the command in father's directory, I get an empty result.
So the error is misleading, and apparently I don't know how to set up PyCharm in this case.
Is there a way to fix this?
I got it. I think it makes sense answering my own question.
The structure of my project is the following:
Project root (no VCS)
RepoDir (hg repository)
SubRepoDir (hg subrepository)
In this configuration something confuses PyCharm, and subrepositories at third level
won't be recognized.
The following works pretty well:
RepoDir as Project root (hg repository)
SubRepoDir (hg subrepository)
If other directories are needed, one can add them as content root.

hg locate command empty output

I have a problem on a repository. I use phabricator as the front-gui of my repository. Recently I found I am not able to open and view a few directories in one repository in phabricator while other directories are fine. Phabricator reports 'hg locate' command output is empty like this:
Command failed with error #1!
COMMAND
hg locate --print0 --rev ''\''d8f8fd40c58bf883ec88bd037f96b962ec16f48e'\''' -I './/OA'
STDOUT
(empty)
STDERR
(empty)
I tried the same command in the repository on the server and I did get no output. So I just simply tried the command 'hg locate' without any parameter. That command is supposed to list all the files in the repo but I found the output was still empty!
I then cloned the repo to another directory on the server and tried the same 'hg locate' command and found it was find and I got the file list in the repo.
What is the problem with my original repo? Is there any setting to prevent the 'hg locate' command to output anything?

mercurial diff + unxutil "patch"

How do you make the mercurial "diff" command produce output that is compatible with the unix or unxutil patch command?
I need to create a patch file that I can send to a coworker who doesn't have Mercurial installed.
I've tried using hg diff -r 3:5 > patch1.diff and I get an error from the patch command when applying it. (hold on, I will post the error message as soon as I have a chance....)
OK, here is a test case that I've uploaded to bitbucket:
hg clone https://bitbucket.org/jason_s/test-patch-apply P2base
hg update -r 2 -R P2base
hg diff -r 2:4 -R P2base > p2base.patch
rm -r P2base/.hg
cd P2base
patch < ../p2base.patch
I get this on my Windows PC:
C:\tmp\hg\P2base>patch < ../p2base.patch
patching file bar.txt
Assertion failed: hunk, file ../patch-2.5.9-src/patch.c, line 354
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
Never mind, this is a documented problem (with a REALLY POOR ERROR MESSAGE) that can be overcome. From http://gnuwin32.sourceforge.net/packages/patch.htm :
On MS-Windows, the patchfile must be a text file, i.e. CR-LF must be
used as line endings. A file with LF may give the error: "Assertion
failed, hunk, file patch.c, line 343," unless the option '--binary' is
given.
I used --binary and it worked fine.

TortoiseHg can't commit--"The system cannot find the file specified"

I just picked up TortoiseHg to use for distributed source control on Windows and installed it on my C drive. Then I created a repository (located in D:\projects).
When I try to commit the changes, it gives me the error
"abort: None: The system cannot find
the file specified"
in a new window titled "Commit". This causes the commit to abort. It doesn't specify any file, and when I run hg --traceback commit -m 'Message' it gives this as output:
Traceback (most recent call last):
File "mercurial\dispatch.pyo", line 54, in _runcatch
File "mercurial\dispatch.pyo", line 483, in _dispatch
File "mercurial\dispatch.pyo", line 351, in runcommand
File "mercurial\dispatch.pyo", line 534, in _runcommand
File "mercurial\dispatch.pyo", line 488, in checkargs
File "mercurial\dispatch.pyo", line 481, in <lambda>
File "mercurial\util.pyo", line 420, in check
File "mercurial\commands.pyo", line 762, in commit
File "mercurial\cmdutil.pyo", line 1202, in commit
File "mercurial\commands.pyo", line 757, in commitfunc
File "mercurial\localrepo.pyo", line 816, in commit
File "mercurial\localrepo.pyo", line 1053, in status
File "mercurial\dirstate.pyo", line 629, in status
File "mercurial\dirstate.pyo", line 540, in walk
File "mercurial\localrepo.pyo", line 796, in fail
Abort: Adding: The system cannot find the file specified
abort: Adding: The system cannot find the file specified
I don't know what else I can give as debug info, not having any experience with the program.
I have configured TortoiseHg with both a username globally and for the repository. Also, kdiff3 is specified as both the three-way merge tool and the visual diff tool. I have not knowingly changed any other settings.
Thanks for any help, and please ask for more information, I just don't know what to give in this situation.
I'm getting acquainted with Hg and trying Tortoise-Hg out and I'm running to the same exact issue as the OP. I cloned a repository
from one of the open source projects and made some changes to the source.
However when I attempt to commit, I get the follow message from the commit
dialog window:
abort: None: The system cannot find the file specified
Dropping down to commandline and using hg commit -m "message" works. I'm
using this under Windows 7 64-bit and have tried two versions TortoiseHg 1.1.5 and
the latest 1.1.6.1(64-bit version) as of this post.
Any idea what the problem is? As you can imagine, this is a major issue since I can't even do one of the most basic operations for a version control system w/o needing to drop down to CLI. What is wrong with this?
Thanks
Update: I have SOLVED the issue! After some collaboration on the TortoiseHg mailing-list, I've identified the root cause of this error. This error is happening because whenever tortoisehg tries to commit it's tacking on an extra 'none' parameter to the end of that commit command line.
This can happen if you've set your repository settings->Commit->Auto Commit List to 'None'. The fix is simple -- make sure that Auto Commit List and Auto Exclude List are both set to < unspecified >. Check your global settings as well and make sure these 2 fields are set the same way.
Additionally, to see if your Auto Commit List and Auto Exclude List are set properly type
hg showconfig --debug tortoisehg
If it contains a line something to this effect:
mercurial.ini:15: tortoisehg.autoinc=None
then tortoisehg isn't configured properly.
I hope this solves the issue for the OP and others that are running into this problem and pulling their hair out trying to fix it.
Try this:
Remove TortoiseHG
Restart the system (basically to make sure there are no processes from tortoise, such as file monitoring, that can put locks on files)
Intall command line hg
do the regular hg commit -m "yourmessage"
If this works, it's more likely than not that the monitoring tool from TortoiseHg is holding a lock on some file (the system tray applet).
It also could be the case that someone else is doing than (not TortoiseHg), e.g. editor? diff tool? etc?
Finally, another reason why this can happen is: someone fooled around with the repo files inside .hg directory... It doesn't seem to be the case though

Help getting Mercurial running on a Media Temple (gs)

I've installed Mercurial per MT's knowledge base file here.
Working with it server side using ssh from my Mac works fine. I can initialize repositories and the like, but pulling from the server or pushing from my Mac produces an error I don't understand.
Here's what I get when call hg push from my local installation (hash marks represent my server number):
remote: Traceback (most recent call last):
remote: File "/home/#####/users/.home/data/mercurial-1.5/hg", line 27, in ?
remote: mercurial.dispatch.run()
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/dispatch.py", line 16, in run
remote: sys.exit(dispatch(sys.argv[1:]))
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/dispatch.py", line 21, in dispatch
remote: u = _ui.ui()
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/ui.py", line 38, in __init__
remote: for f in util.rcpath():
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/util.py", line 1200, in rcpath
remote: _rcpath = os_rcpath()
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/util.py", line 1174, in os_rcpath
remote: path = system_rcpath()
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/posix.py", line 41, in system_rcpath
remote: path.extend(rcfiles(os.path.dirname(sys.argv[0]) +
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/posix.py", line 30, in rcfiles
remote: rcs.extend([os.path.join(rcdir, f)
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/demandimport.py", line 75, in __getattribute__
remote: self._load()
remote: File "/nfs/c05/h01/mnt/#####/data/mercurial-1.5/mercurial/demandimport.py", line 47, in _load
remote: mod = _origimport(head, globals, locals)
remote: ImportError: No module named osutil
abort: no suitable response from remote hg!
Mercurial on my Mac is configured as follows
[ui]
username = John Smith
editor = te -w
remotecmd = ~/data/mercurial-1.5/hg
My local single repo is configured as follows (hash marks represent my server number):
[paths]
default = ssh://mysite.com#s#####.gridserver.com/domains/mysite.com/html
Mercurial on the server is configured with a just a username:
[ui]
username = John Smith
The server .bash_profile is configured as follows (per the installation guide):
# Added this as suggested by the MediaTemple guide
export PYTHONPATH=${HOME}/lib/python:$PYTHONPATH
export PATH=${HOME}/bin:$PATH
I understand this probably isn't a MediaTemple problem, but more likely an installation problem. I would really appreciate any assitance on this. Thanks in advance!
Your mercurial installation isn't complete, you didn't compile the osutil module (there should be a osutil.so somewhere).
#tonfa,
hgdebuginstall produced no errors, which is why the problem I was having was so weird.
Thanks to your response, I did some digging and found the module in ~/lib/python/mercurial, so I copied the osutil.so file over to my ~data/mercurial-1.5/mercurial directory and that was that... but then more and more modules couldn’t be found so I decided to copy the entire contents of one directory over to the other, like so:
$ rm -R ~/data/mercurial-1.5/mercurial/*
$ cp -r ~/lib/python/mercurial/* ~/data/mercurial-1.5/mercurial
Now, everything works fine. I don't understand why it seems that mercurial was installed in two directories, or why one directory (~/data/mercurial-1.5/mercurial) didn't get the same files as the other (~/lib/python/mercurial).
Anyway, this is the solution I came up with. If you (or anyone) can think of something more elegant, I'd be all ears, but as it is... this one works for me.
Thanks for your time.