0

Mercurial の分散型の性質にもかかわらず、私たち全員がプッシュし、夜間のビルド、パッケージングなどを行う集中型サーバーがあります...

私たちが達成したいことは次のとおりです。ソース管理されているファイルの 1 つに、理想的にはコミットごとに増やす必要があるメジャー + マイナー バージョン番号が含まれています。開発者のマシンでは集中番号付けができないため、コミットがプッシュされるたびに新しいマイナー バージョン番号をそのファイルに書き込む、メイン サーバー上のプリコミット スクリプトを考えていました。問題は次のとおりです。

  • プリコミットなので、このファイルの変更は同じコミットの一部になることができますか?
  • そうでない場合、プリコミットが別のコミットを引き起こす可能性がありますか?また、それがカスケード/再帰するのをどのように防ぎますか?
  • どうやってそれをしますか？
  • より良い解決策はありますか？
4

2 に答える 2

4

「precommit」スクリプトは、コミット時にのみトリガーされます。ユーザーが「中央」サーバーにプッシュするまでには、すでにコミットされており、precommit フックで何かを行うには遅すぎます。changegroup開発者がプッシュしたときに「中央」サーバーで実行するようにトリガーされるフックを持つことができますがincoming、それらはコミットを変更できません-コミットはその時点ですでにコミット/ベイク/完了されており、それらに反応することしかできません.

提案として、実際にはファイルにバージョン文字列を入れないでください。コミットごとに変更されるファイルを持つと、マージが面倒になります。代わりに、次の 1 つ以上を実行します。

  • CI サーバー (Jenkins など) にすべてのプッシュでビルドを実行させ、ビルド スクリプトに渡すことができる Jenkins ビルド番号を使用します。
  • バージョン文字列の一部として Mercurial ノード ID (ハッシュ) を使用すると、ビルドに含まれるリビジョンを常に正確に把握できます。ファイルに格納せず、ビルド (またはデプロイ) スクリプトでクエリを実行するだけです。
  • フックを使用しchangegroupて自動的にタグ オン プッシュを行います。これにより、きれいな (場合によっては連続した) 名前がコミットに適用されます (すべてのタグがコミットであるため、これによりコミット数がほぼ 2 倍になることに注意してください)。

個人的には、ビルド スクリプトで次のようなものを使用します。

build.sh --version_string=$(hg log -r . --template '{latesttag}.{latesttagdistance}-{node|short}')

1.0.3-5fd8ed67272eこれは、「バージョン 1.0 が nodeid 5fd8ed67272e でタグ付けされてからの変更セットの 3 つのコミットから構築された」と大まかに読むことができる" " のようなバージョン文字列を取得します。コンパイルに（コンパイルされた言語の場合）、またはVERSIONデプロイスクリプトがサーバーにアップロードするときにファイルに書き込みます。

于 2012-04-13T23:09:55.120 に答える
0

この問題に関するコメントやアイデアについては、Mercurialのドキュメントのこのページを参照してください。Mercurialでいくつかのバージョンキーワードを拡張する方法も参照してください。そしてそこで参照されている他のSO回答。

于 2012-04-19T11:46:38.047 に答える