Mercurial预推钩扫描工作副本 [英] Mercurial pre-push hook scanning the working copy

问题描述

我需要在人们可以推送的存储库上设置一个挂钩，这将运行一些验证(目标是如果验证失败，则拒绝推送).我已经有一些挂钩设置，可以在成功推送后自动更新，并防止出现多个头部.

I need to setup a hook on a repository where people can push, that would run some validation (the goal is to reject the push if validation fails). I already have some hooks setup to auto-update after a successful push, and prevent multiple heads.

我编写验证脚本(例如运行单元测试的shell脚本)没有问题，但是它需要在完整的工作副本上运行.

I have no problem writing a validation script (for example a shell script that runs unit tests), but it needs to run on the full working copy.

我的问题是，如果仅将其放在pretxnchangegroup挂钩中，它将无法对更新的文件进行操作.如果我尝试在挂钩中进行hg更新，则每当验证失败并回滚推送时，都会导致存储库损坏.

My problem is that, if I just put it in a pretxnchangegroup hook, it does not operate on updated files. If I try to hg update inside the hook, this leads to repository corruption whenever validation fails and the push is rollbacked.

我当前的解决方案是将存储库克隆到某个临时文件夹并在其中运行实际验证.但是我发现这有点丑陋，并且就地验证仅执行更新的效率较低.这种钩子可以设置吗?

My current solution is to clone the repository to some temporary folder and run the actual validation there. But I find this a bit ugly, and it is less efficient that an in-place validation doing just updates. Is this kind of hook possible to setup ?

推荐答案

有很多方法可以做到，但是在我开始之前，您确定要这样做吗?在一个钩子中进行阻塞性的，可能是缓慢的，推送拒绝的更改会使人烦恼，并且始终保持存储库的写锁，因此在运行验证脚本时，没有其他人可以推送.人们可以很容易地将DVCS的一半生产力优势抛诸脑后，以期获得一点控制权.

There are ways to do this, but before I start, are you sure you want to do this? Doing blocking, maybe-slow, push-rejecting changes in a hook annoys the hell out of people, and it holds the repository writelock the whole time, so no one else can be pushing while the validation script is running. One can pretty easy toss half the productivity advantages of a DVCS out the window in an attempt to gain a little control.

使用两层存储库设置可以避免大多数缺点.诸如project-push之类的东西，人们可以不通过验证而推送，而project-pull之类的只有变更集通过了某些验证.然后，您将获得一个带外(触发cron或hook的)脚本，仅在确认确认后才将变更集从project-push移至project-pull.因为该测试是在带外完成的，所以不会阻止推送，但是非验证的变更集永远不会将其放入project-pull中.当作者的推键将project-pull置于无效状态时，您可以通过电子邮件发送给作者.像这样配置.hg/hgrc的用户完全不必考虑自己是两个存储库:

You could avoid most of those disadvantages with a two-tier repository setup. Something like project-push where people can push w/o passing validation and project-pull that only has changesets which passed some validation. Then you have an out-of-band (cron or hook triggered) script that moves changesets from project-push to project-pull only after validation is confirmed. Because that test is done out of band pushes aren't blocked but non-validating changesets never make it into project-pull. You can have it email the author when their push threw project-pull into a non-validating state. Users with their .hg/hgrc configured like this wouldn't have to think about their being two repositories at all:

[paths]
default=http://host//path/to/project-pull
default-push=http://host//path/to/project-push

他们只需使用hg push和hg pull，事情就会正常".

They could just use hg push and hg pull and things would "just work".

也就是说，如果您的验证不需要同时访问所有更新的文件，则可以在外部pretxnchangegroup挂钩中使用类似的方法进行测试:

That said if your validation doesn't need access to all the updated files at the same time you can do your test with something like this in an external pretxnchangegroup hook:

for thefile in $(hg manifest -r tip) ; do
  if ! hg cat -r tip $thefile | ./validate_on_file.sh ; then
     exit
  fi
done

如果确实需要一次对所有文件进行操作(编译等)，并且您不愿意执行两个仓库结构来释放人们的快速推动力，那么您确实需要单独的仓库进行测试，但您不必每次都克隆/创建它. pretxnchangegroup挂钩中的类似内容应该可以做到:

If you do need to operate on all the files at once (compiling, etc.) and you're not willing to do a two-repo structure that frees people to push quickly, then you do need a separate repo for testing, but you don't have to clone/create it each time. Something like this in a pretxnchangegroup hook should do:

hg push /scratch/long-lived-testrepo ## Warning: may not work,  
                                     ## if pretxnchangegroup locks the repo and  
                                     ## blocks this push to testrepo
hg -R /scratch/long-lived-testrepo update
cd /scratch/long-lived-testrepo
./validation.sh

这篇关于Mercurial预推钩扫描工作副本的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！