I'm having difficulty cloning a repository in Mercurial.
The repository is stored at Kiln on demand, though I'm not sure that makes much difference.
I have a new install of Tortoise HG, which has of course installed the hg command line onto my machine.
When I attempt to clone the repository, I immediately receive the error:
abort: The system cannot find the path specified: 'F:\backups\_hgcookies'
Code: 255
I don't know where it's getting this path from - there is an 'F' drive on my machine that is completely empty aside from hidden system volume files.
The Kiln Tortoise install contains a couple of plugins bundled with it, including kilnauth, which I assume is using a cookie to store authentication information.
I've looked in the mercurial.ini file, however it contains no mention of this folder or hgcookies - that I can see.
I'm wondering if there's a permissions issue somewhere - I'm in the administrators group on the machine, but am on a company network with quite a bit of lockdown which has caused problems before.
I've not found any similar problems through googling, though it's been difficult to get relevent results with the word 'backup' and 'hgcookies' in my terms!
Any help, greatly appreciated.
Seems this was an issue with the KilnAuth extension. I'm not sure why it decided to store the cookies on the F: drive, but I manually created a 'backups' folder on that drive and that allowed it to store the cookie there with no problems.
I had some help from the FogCreek guys diagnosing this - I have to say I've never experienced such awesome customer service, really. Hats off to those guys!
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
I'm using easy mercurial. I have changed a computer, but still use same account for my repository. when I pushing things to my repository, it always failed.
The prompt said: A Mercurial command failed to run correctly. This may indicate an installation problem or some other problem with EasyMercurial.
More Detail showed: warning: code.soundsoftware.ac.uk certificate with fingerprint 74:51:c7:c4:9b:85:de:05:02:2f:9f:ec:7f:16:25:4c:68:48:74:7c not verified (check host finger prints or web.cacerts config setting)
I use windows 7 and the installation is correct. I re-installed it many times, but it always failed to push. Then I used my old computer, re-installed the Mercurial, but it also fail to push. But I can push things correctly in my old computer before I uninstalled Mercurial in it. And I didn't find solution in wiki for my problem. Could anyone help me? What should I do? That's an emergency, I need to solve this as soon as possible!
Thanks!
Based on your error message it seems that mercurial is not trusting the host you are trying to push to.
Try add this to your .hg/hgrc file in the top level of your repository (if it doesn't exist, create a file called hgrc (no extension) in the .hg directory and open it with a text editor and add this):
[hostfingerprints]
code.soundsoftware.ac.uk = 74:51:c7:c4:9b:85:de:05:02:2f:9f:ec:7f:16:25:4c:68:48:74:7c
If that works, you may want to add the same to %USERPROFILE%\Mercurial.ini if you are pushing to that server from multiple repositories.
reference: mercurial hgrc files hostfingerprints
I am following the directions here trying to get Mercurial running on my shared HostGator account.
I am supposed to create a "hg" directory, but I am unsure if it is to be in the /home/user/ location or in /home/user/domain-I-want-to-version-control/. I actually tried creating that directory, and the modified 'index.cgi' inside. When I then navigate to (url)/hg I get an internal server error.
Could really use some guidance, please.
Never create repository this way! If you want to add Mercurial repo for existing code (did you try to verify, that you have working hg?!) read before it QuickStart Guide at least
I'm running into a problem with a user not being able to push his commits into a Mercurial repository and am perplexed as to why it's not working for him. I've tried several things to figure out what's up, Googling doesn't turn up anything helpful... so here I am.
First, the configuration. We have a Windows XP SP2 x64 machine on our network acting as our official repository server. This contains several repositories on it. We clone / push / pull using a folder on that drive that is shared. Permissions are given to everyone for read access. Users that can push (including the user that has problems), are given full control. The user's machine is Win XP based. My machine (used to help troubleshoot things) is also Win XP based.
Second, the symptoms. The user is using TortoiseHg 2.1.1 to do his work. He can clone just fine, commits to his local repo are a-o-k, etc. When he tries to push, however, TortoiseHg returns a "abort, ret 255" code. Not very helpful. So, we've gone to the command line and have issued "hg push -v --debug". Here it returns "abort: Access is Denied". This same user can write to the server's shared folder no problem -- he can create files, directories and delete the same as well. So, reading / writing access the drive / folder is not an issue.
Third, our experimentation results. Here are some weird results from testing. The user created a new, local test repo. I logged into the server machine and created a test repo for him to push to. The user checked in a file and then pushed it up to the test repo on the server machine. This worked fine. No aborts. Life was good. He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message. Meanwhile, I can still update the project without any problems.
As another experiment, we had the user log out and another user log in. They did so and were able to push to the server repo without a problem. Original user logs back in, makes some changes, etc. and once again hits the brick wall of "Access is Denied".
As far as we can tell, the problem is not related to Windows credentials. Otherwise, we'd expect that creating arbitrary files on the server's shared folder would not work. Further, until I made an update to the test repo the user created, he could push to that particular repo just fine.
Any ideas? What additional credential checks is Mercurial making that might cause this?
UPDATE:
After a tip from Wim, I started to look at the permissions on the various objects of the repo using 'cacls'. This is a Windows tool that "displays or modifies access control lists of files". I had the user create a new repo and then took a snapshot of the permissions. I then checked in a file to the same repo and took another snapshot of the changes.
It turns out that there are several repo file permissions that get updated as a result of this: undo.bookmarks, undo.branch, undo.desc, undo.dirstate, branchheads, 00changelog.i, 00manifest.i, undo, and the single file of the repository. All of these files had permissions similar to the following:
C:\Projects\Mercurial\hgtest4\.hg\store\undo BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
DOMAINxxxx\USERIDxxxx:F
BUILTIN\Users:R
(actual DOMAINxxxx and USERIDxxxx values have been altered). Prior to my check-in, DOMAINxxxx & USERIDxxxx reflected the user's domain and userid. After my check-in, these got updated to mine (we're on the same domain, but the userid is obviously different.) I was able to check things in and out even though my userid wasn't listed because I'm a member of the BUILTIN\Administrators group. The user with the problem is not. So, I'm guessing that after I checked things in, the system no longer saw him as a credentialed user with write-access (BUILTIN\User:R indicates Read-only access) and therefore caused the access denial.
I've got a terribly Q&D fix in place right now (user is now part of the Admin group...) The real fix is going to be to get the repo off of Windows Sharing and on to a proper server configuration.
He was able to do a few more pushes and it continued to work as expected. I then cloned the repo to my machine, updated a file, and pushed it back out. After the user then pulled in my changes and tried to push back to the server, he once again encountered the dreaded "Access is Denied" message.
It sounds like your push creates or modifies files in the .hg folder in such a way that they are (or become) inaccessible for the other user.
I'm no expert on NTFS file permissions, but I think you can fix such situations by forcing all the content of the folder to inherit its permissions. Try selecting "Replace all child object permissions with inheritable permissions from this object" in the Advanced Security settings of the folder.
However, sharing the repository files directly with Windows file sharing is not recommended. You need a server process between the users and the repository files for the sake of performance, data integrity and security. Without such a gatekeeper, granting commit access also means granting the ability to destroy/corrupt the repository files (or as you found out in this case, changing their permissions).
See Publishing Mercurial Repositories on the Mercurial wiki for more information about other options.
When trying to commit on my locally cloned repository of a code repo on my network share, I was getting the same error message:
00manifest.i Access is denied
Probably overly simplistic, but removing some of the read only permissions to the offending files made my hg commit work fine.
I just had the same issue abort: Access is denied. The cause was my firewall (Privatefirewall) silently blocking some actions of hg.
I was getting exactly the same error message when trying to hg push at the windows command prompt. I'd recently received a new user profile after the old one had corrupted. I then ran into this "Access Denied" error. In TortoiseHg I received a similar message of "Aborted: Error 255".
I tried the advice given here by Wim Coenen as it seemed to fit; given my new user credentials. Eventually, I tracked the error to a badly installed Windows Git. It was only failing when I used repositories with git sub-repos.
In case others are having a similar problem with Git sub-repos:
Check that Git is installed correctly. I removed and re-installed it completely. (See: https://code.google.com/p/msysgit/downloads/list for latest version).
Ensure that the path to Git is in the path environment variable. (Right-click My Computer -> Advanced tab -> Environment Variables). Don't forget that some applications do not like windows paths with spaces in so you might need to replace "Program Files" with "PROGRA~1" (possibly "PROGRA~2" on 64-bit systems).
If you are using a proxy, ensure that HTTP_PROXY and HTTPS_PROXY in the environment variables are also set correctly.