mercurial - 在推/拉之前自动触发 Hg 存储库验证，无需编程

Question

我们发现我们的 Hg 存储库在几周前已损坏。这种损坏似乎已经蔓延:所有克隆(中央存储库和用户存储库)都以同样的方式被损坏，而且非常严重。我认为如果我们当时进行验证的话，我们是可以避免这种情况的。

是否有一些 Hg 设置会导致每次推送时进行验证，并在验证失败时阻止推送？我知道我可以将它实现为 Python 中的钩子(Hook)，但是是否有更简单的解决方案？

是否也可以做相反的事情:确保在拉取之前验证远程存储库？

FWIW，我使用的是 Windows 10，我们使用的是 TortoiseHg。

更新:我已经尝试按照 Jordi 的建议创建钩子(Hook)。 Hg 现在挂起等待锁。这是我所看到的:

c:\Users\username\test-hook>hg init
c:\Users\username\test-hook>cd ..
c:\Users\username>hg clone test-hook test-hook-clone
updating to branch default
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

# At this point I edited clone repository settings to include
# [hooks]
# preoutgoing = hg verify
#
# Then I created a test.txt file and "added" it via TortoiseHg context menu.

c:\Users\username\test-hook-clone>hg commit
c:\Users\username\test-hook-clone>hg status

c:\Users\username\test-hook-clone>hg outgoing
comparing with c:\Users\username\test-hook
searching for changes
changeset:   0:a61d33af6cdb
tag:         tip
user:        username
date:        Mon May 06 20:32:54 2019 +0200
summary:     test file added

c:\Users\username\test-hook-clone>hg push -verbose
pushing to c:\Users\username\test-hook
searching for changes
running hook preoutgoing: hg verify
waiting for lock on repository c:\Users\username\test-hook-clone held by process '16840' on host 'LT407233'

Answer 1

为了回答你的问题，钩子(Hook)不必用Python编写。在适当的服务器的 hgrc 中(在存储库级别或系统级别)，只需设置

[hooks]
preoutgoing = hg verify
preincoming = hg verify

这可能会显着减慢所有拉和推操作的速度，但也许您愿意为了正确性而牺牲速度。

当客户端尝试从损坏的存储库中提取数据时，这将导致如下输出:

$ hg clone http://localhost:9000 sample-repo
requesting all changes
remote: abort: preoutgoing hook exited with status 1

并且在您的服务器日志中，您应该看到类似于以下内容的输出

127.0.0.1 - - [18/Apr/2019 12:41:09] "GET /?cmd=batch HTTP/1.1" 200 - x-hgarg-1:cmds=lheads+%3Bknown+nodes%3D x-hgproto-1:0.1 0.2 comp=zstd,zlib,none,bzip2 partial-pull
checking changesets
checking manifests
crosschecking files in changesets and manifests
checking files
 a@0: broken revlog! (index data/a.i is corrupted)
warning: orphan data file 'data/a.i'
checked 2 changesets with 1 changes to 2 files
1 warnings encountered!
1 integrity errors encountered!
(first damaged changeset appears to be 0)