3

人々がプッシュできるリポジトリにフックをセットアップする必要があります。これにより、検証が実行されます (検証が失敗した場合にプッシュを拒否することが目標です)。プッシュが成功した後に自動更新するようにいくつかのフックがセットアップされており、複数のヘッドが防止されます。

検証スクリプト (たとえば、単体テストを実行するシェル スクリプト) を書くのに問題はありませんが、完全な作業コピーで実行する必要があります。

私の問題は、それを pretxnchangegroup フックに入れるだけでは、更新されたファイルで動作しないことです。フック内で hg update を実行しようとすると、検証が失敗してプッシュがロールバックされるたびにリポジトリが破損します。

私の現在の解決策は、リポジトリを一時フォルダーに複製し、そこで実際の検証を実行することです。しかし、これは少し見苦しいと思います。更新だけを行うインプレース検証よりも効率が悪いです。この種のフックはセットアップできますか?

4

1 に答える 1

3

これを行う方法はいくつかありますが、始める前に、これを実行しますか? フックで変更をブロックする、おそらく遅い、プッシュを拒否することは、人々を悩ませ、リポジトリの書き込みロックを常に保持するため、検証スクリプトの実行中に他の誰もプッシュすることはできません。少し制御しようとして、DVCS の生産性の利点の半分を簡単に捨てることができます。

2 層リポジトリのセットアップを使用すると、これらの欠点のほとんどを回避できます。project-push検証に合格せずに人々がプッシュでき、project-pullいくつかの検証に合格したチェンジセットしかないようなもの。次に、検証が確認された後project-pushにのみ変更セットを から に移動する帯域外 (cron またはフックがトリガーされる) スクリプトがあります。project-pullそのテストは帯域外で行われるため、プッシュはブロックされませんが、検証されていないチェンジセットがproject-pull. プッシュがproject-pull非検証状態になったときに作成者に電子メールを送信するように設定できます。このように構成されたユーザーは、.hg/hgrc2 つのリポジトリであることをまったく考える必要はありません。

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

彼らはhg pushandを使用するだけでhg pull、物事は「うまくいく」でしょう。

つまり、検証で更新されたすべてのファイルに同時にアクセスする必要がない場合は、外部pretxnchangegroupフックで次のようなものを使用してテストを実行できます。

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

一度にすべてのファイルを操作する必要があり (コンパイルなど)、人々がすばやくプッシュできるようにする 2 つのリポジトリ構造を使用したくない場合は、テスト用に別のリポジトリが必要ですが、毎回クローン/作成する必要はありません。pretxnchangegroupフックで次のようなことを行う必要があります。

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
于 2012-02-16T14:52:18.377 に答える