Tortoisehg 推送或提交失败并显示“ret 255”

Question

我使用 Tortoisehg 已经有一段时间了，几乎没有问题，但遇到了以下问题：

我无法推送或提交到我的主存储库。我对项目中的一个文件进行了小改动，在本地提交没有问题，但推送到主仓库失败：

% 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]

主存储库位于（Windows）文件服务器上，我从 Windows 机器提交。我确信我没有用完配额。 我没有更改主仓库的权限，我是所有数据的所有者，并且还尝试为自己分配“完全控制权”（默认情况下，我只有读写权限——实际上不知道有什么区别），但无济于事.

我还尝试在主仓库中编辑更改的文件并在那里提交：

% 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]]

现在，有趣的是，Mercurial 抱怨的文件似乎一开始并不存在。该目录中只有一个名为_g_e_m.py.i 的文件。我确保在文件管理器中显示了隐藏文件，并且我也从 Linux 中查看，只是为了确保。 我还尝试将 repo 克隆到不同的位置，然后推送到新的 repo，但这没有任何改变。

我在此站点上找到了this answer，但我在 repo 文件夹中没有文件 .hg/wlock（或任何类似名称的文件）。

更新： 由于被问到：主 repo 上 .hg/store/data 目录的权限是：

.hg [domain]\Domain Admins:(I)(OI)(CI)(F)
    NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
    [domain]\[user]:(I)(OI)(CI)(M)

在我的本地，它是：

.hg Everyone:(I)(OI)(CI)(F)

所以有区别。在 .hg 目录中，可能是因为我在尝试单独解决问题时弄乱了权限，有这样的：

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)

是的，这是我的用户名，两次。更改权限时我可能违反了一些约定...我可以使用 Posix 权限，但这对我来说有点不透明。

一个潜在的线索：tortoisehg 很有可能在问题出现之前就崩溃了，或者失去了网络连接。我在家里使用 VPN，这种事情可能会发生。因此，如果 Mercurial 阻止任何文件/目录，则可能会有一些阻止，尽管我不知道如何验证/修复它。自问题出现以来，所有可能负责阻止该目录的机器都已重新启动 - 当然托管数据的文件服务器除外。

我还更新了上面的语句以添加--debug 输出。文件名后面的随机字母/数字发生了变化，因为我在文件中进行了更多更改。这表明它实际上不是那个特定的文件（无论如何都不存在），而是 mercurial 尝试写入的目录。

Answer 1

我不太确定问题的原因是什么，但这是我绕过它的方法：

• 我将远程存储库克隆到本地计算机上
• 我打开本地仓库，单击“同步”按钮并将默认路径从功能失调的远程仓库更改为新克隆的仓库
• 我推送了更改 - 效果很好！
• 我将“本地化”远程 repo 克隆回网络驱动器
• 我再次将本地存储库的默认路径更改为新的远程克隆
• 我用另一个提交和推送测试了新的远程存储库，影响了同一个文件，并且一切正常。

现在一切都好，虽然我仍然不知道首先出了什么问题，以及为什么在网络驱动器内克隆没有帮助，但克隆到本地 repo 有帮助。 我最好的猜测是它结合了 Windows（7？Server？）定义文件权限的方式，以及 Tortoise 和/或 Mercurial 在推送/克隆时设置它们的方式。

我当然希望这种情况不会很快再次发生，因为如果我现在不得不更频繁地这样做会非常烦人。

更新

问题再次发生，并且在其他 repos 中也发生了。推送到共享驱动器上的存储库时一定会发生这种情况，但不是每次都发生。可能是在推送新的头部时，或者在推送之前尚未拉取共享仓库中的更改。我发现 .hg/ 子目录中文件的扩展属性存在一些差异，但我对 Win7/server 扩展属性和 torrtoiseHG 的工作方式都不够熟悉，无法理解这一点。

我现在已经停止使用那个特定的共享驱动器并切换到使用 NAS 设备，并且那里没有出现问题。

Answer 2

TortoiseHg push “ret 255” 存在 90% 权限问题。 如果您使用服务器中的共享文件夹检查当前用户的 Mercurial 存储库的权限，请为该用户的文件夹添加修改和写入权限。 另外，检查属性，它不应该是“只读”。

我们网络中的一位用户遇到了同样的问题，这有助于我让他工作。 如果有人有其他问题并成功解决，请添加 cmets。