问题
I've been using Tortoisehg for a while now, with little to no problems but have just run into the following problem:
I cannot push or commit to my main repository. I made a small change to one file in my project, committed locally with no problem, but the push to the main repo fails:
% hg --debug push "Z:\[main repo]"
pushing to Z:\[main repo]
query 1; heads
searching for changes
all remote heads known locally
listing keys for "bookmarks"
1 changesets found
list of changesets:
09d372b8d90710f2ad772dc4164fd640d6869208
adding changesets
add changeset 09d372b8d907
adding manifests
adding file changes
adding GEM.py revisions
transaction abort!
rollback completed
abort: Permission denied: Z:\[main repo]\.hg/store\data\._g_e_m.py.i-dmz4wn
[command returned code 255 Thu Mar 09 14:17:01 2017]
The main repo is on a (Windows) file server, and I am submitting from a Windows machine. I am sure that I have not run out of quota. I have not changed permissions on the main repo, I am owner of all data and have also tried assigning myself "full control" (by default I have only read and write -- not sure what the difference is, actually), to no avail.
I also tried editing the changed file in the main repo and committing there:
% hg commit --verbose "--message=GEM.py: [message]" --user [user] -- "Z:\[main repo]\GEM.py"
GEM.py
trouble committing GEM.py!
abort: Permission denied: Z:\[main repo]\.hg/store\data\._g_e_m.py.i-kbxvue
[command returned code 255 [date]]
Now, an interesting thing is that the file that Mercurial complains about does not seem to exist in the first place. There is only a file called _g_e_m.py.i in that directory. I made sure to have hidden files shown in the file manager, and I've also looked from Linux, just to make sure.
I also tried cloning the repo to a different location, then pushing to the new repo, but that changes nothing.
I have found this answer on this site, but I do not have a file .hg/wlock (or anything named similarly) in the repo folder.
Update: Since was asked: The permissions for the .hg/store/data dir on the main repo are:
.hg [domain]\Domain Admins:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
[domain]\[user]:(I)(OI)(CI)(M)
On my local one, it's:
.hg Everyone:(I)(OI)(CI)(F)
So there's a difference. Within the .hg directory, probably as consequence of me messing with permissions while trying to solve the problem alone, there's this:
store\data [domain]\[user]:(OI)(CI)(F)
CCNT\Domain Admins:(I)(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
[domain]\[user]:(I)(OI)(CI)(M)
Yes, that's my username, twice. I may have violated some conventions when changing permissions... I'm okay with Posix permissions but this is a bit opaque to me.
A potential clue: It's quite possible that tortoisehg crashed before the problem appeared, or lost network connection. I was working with VPN from home, and that sort of thing can happen. So if Mercurial blocks any files/directories, there might be some block in place, though I wouldn't know how to verify/fix that. All machines which might have been responsible for blocking the dir have rebooted since the problem appeared -- except of course for the file server hosting the data.
I've also updated the statements above to add the --debug outputs. The random letters/numbers behind the filename changed, because I put some more changes into the file. That would indicate that it's really not that particular file (which does not exist anyway) but the directory which mercurial attempts to write into.
回答1:
I'm not quite sure what the reason for my problem was but here is how I bypassed it:
- I cloned the remote repository onto my local machine
- I opened my local repo, clicked the "synchronize" button and changed the default path from the dysfunctional remote repo to the newly cloned one
- I pushed the changes -- works fine!
- I cloned the "localized" remote repo back to the network drive
- I changed the default path on my local repo again, to the new remote clone
- I tested the new remote repo with another commit and push, affecting the same file, and it all works nicely.
It's all okay now, although I have still no clue as to what went wrong in the first place, and why cloning within the network drive did not help but cloning to a local repo did. My best guess is that it's a combination of Windows (7? Server?) way of defining file permissions, and Tortoise and/or Mercurial's way of setting them when pushing/cloning.
I sure hope that this does not happen again soon because it'd be incredibly annoying if I had to do this more often now.
Update
The problem reoccurred, and also happened with other repos. It must be something that happens when pushing to the repo on the shared drive, but not every time. It might be when pushing a new head, or when changes in the shared repo have not been pulled before pushing. I found some differences in the extended attributes of files in the .hg/ subdir but I'm not sufficiently familiar with either Win7/server extended attributes nor torrtoiseHG's workings to make sense of this.
I've now stopped using that particular shared drive and switched to using a NAS device, and the problem does not occur there.
回答2:
TortoiseHg push “ret 255” is in 90% permission problem. If you are using share folder from server check permissions for a Mercurial repository for the current user, add permissions for Modify and Write on a folder for this user. Also, check attributes, it should not be "Read Only".
I had the same problem for one user in our network, it helps me to get him working. If somebody had another problem and successfully soled it, please add comments.
来源：https://stackoverflow.com/questions/42677564/tortoisehg-push-or-commit-fail-with-ret-255