0

我们在远程存储库上设置了一个挂钩，以便在接收到推送后自动更新存储库。它工作得很好，除非我们在本地删除文件然后推送。我们收到这样的消息：

remote:  local changed path/to/file/file.ext which remote deleted
remote: use (c)hanged version or (d)elete? c

它会自动选择“c”。我们有没有办法让 Mercurial 使用 'd' 并删除文件？

这是钩子，也发布在评论中，但希望在这里保留换行符：

[hooks]

changegroup = hg update >&2

incoming = /path/filename.sh > /dev/null 2>&1

.sh 文件在 hg 更新后重置一些权限。

4

2 回答 2

0

一位同事向我指出了这一点，这可能是我们的解决方案：

https://bz.mercurial-scm.org/show_bug.cgi?id=3302

https://www.mercurial-scm.org/repo/hg/rev/95e45abe7e8e

我们还没有尝试过，但我会在我们尝试后报告。

于 2012-10-23T14:19:52.683 回答
0

错误消息的意思是“您的本地工作副本包含更新尝试删除的修改文件。”

如果您在远程服务器上运行“hg st”（即在远程存储库中），您应该会看到修改后的文件。请注意，更改文件的权限被视为更改。

所以会发生这样的事情：

  • 您的本地 Mercurial 将文件推送到远程存储库
  • 挂钩更改远程存储库中的文件（通过修改其权限）。
  • 有人试图删除其中一个文件

Mercurial 总是试图防止数据丢失，因此默认选项是“保留本地更改”（因为您以后可以随时删除这些文件，但您可能无法恢复它们）。

你能做什么？

  • 与其“修复”远程仓库的权限，不如拒绝接受具有错误权限的更改集。也就是说，不是修复权限，而是在pretxnchangegroup挂钩中检查它们。如果权限错误，请中止。这样，只要权限被破坏，您就无法推送。文档。

  • 不要修改工作副本，而是将文件复制到新位置并更改那里的权限。这会浪费一些磁盘空间（但如果您使用软链接或硬链接，则不会像您想象的那么多），但它会分离关注点（来自版本文件的特殊权限）。

[编辑]

新文件，在本地添加然后推送到远程仓库，失去执行权限。

他们没有失去它，他们一开始就没有它：Windows 不支持这个 Unix 特性。

不幸的是，您不能告诉 Mercurial 从 Windows 设置位。

要正确解决此问题，请使用以下方法：

  1. 像以前一样从 Windows 添加和推送文件
  2. 在 Unix 服务器上创建一个 cron 作业，检查权限并发送一封电子邮件，发现它们是错误的。
  3. 当电子邮件进来时，连接到 Unix 服务器并修复权限
  4. 从 Unix 提交并推送更改。

如果您在 Windows 上修改文件，Mercurial 将保留执行位。

我建议将最后两个步骤放入脚本中。我不认为你可以完全自动化它。当有人在运行时推送更改时，脚本将（通常？）失败。

PS：我已经提交了一个功能请求，要求提供更好的解决方案：提供一种从 Windows 修改 Unix 权限的方法

于 2012-10-11T07:10:37.200 回答