私はリビジョン56、ハッシュ6af16aa3edf8です。次のリビジョンは57で、ハッシュは???となります。リビジョン57のハッシュを知る方法はありますか？私は事前コミットのフックでそれが必要です。Mercurial次のコミットハッシュを取得する
なぜですか？
私は、プリコミットフック経由で呼ばれる、いくつかのバージョンファイルを更新するスクリプトを開発しました。このようにして、コンパイルされた実行可能ファイルは、ビルド元のリビジョンに関するすべての情報を与えることができます。現在のコミットのリビジョン番号を私のバージョンファイルに追加しています。単純に "親リビジョン番号+ 1"で検索します。リビジョン番号は同じリポジトリの他の人と共同作業するときには信頼できないため、ハッシュも追加することをお勧めします。それを取得する方法がわからない...
いいえ、チェンジセットが完全にわかっていても、次のハッシュを予測することはできません。コミット時間もありな役割を果たしている：あなたのビルドツールで を、プロジェクトがリポジトリから構築されているかどうかを照会：
~/hg-test $ hg ci -m "b in foo"
~/hg-test $ hg id
d65d61e6898a tip
~/hg-test $ hg rollback
~/hg-test $ hg ci -m "b in foo"
~/hg-test $ hg id
c7f5ff744e43 tip
https://www.mercurial-scm.org/wiki/Nodeid
は、私は、このような問題を解決することをお勧めします。その場合：リポジトリ情報を取得します。例えば。
ver = $(hg log -r. -T"{node|short} from {date|isodate}")
はなるように、パッケージにこのファイルを生成し、修正、配布目的のためにフライ
上のビルド・チェーン内の情報からバージョンファイルを生成し、あなたに
c7f5ff744e43 from 2017-07-26 14:05 +0200
を与えますビルドプロセスは、リポジトリのチェックアウトから起動されていないことが判明した場合でも、それが使用できるバージョンファイルを持っています。
情報とヒントをありがとう。私は何か似たようなことを考えていました。たとえば、現在のリビジョンに基づいてバージョン情報を更新するビルド前のステップのようです。あるコミットから別のコミットにジャンプするときにすべての情報を準備できたらいいのですが...でも –
ビルドステップのその部分を考えてみましょう:) あなたは何らかの継続的な統合を使用しているとしたら、レポ自体とバージョン情報ファイルの生成はビルドの一部です。 配布用にコードをパックすると、バージョン情報付きの小さなファイルを生成するためのパケット作成の一部になります。 – planetmaker
日付を指定してください:) hg commit -m 'msg' -d "2017-01-01 01:01:01" :) – Tom
ハッシュは、ファイルの変更に基づいて**生成されるため、信頼性が低くなります。 – arrowd
@arrowd「信頼できる」とは、改定番号を一意に特定することを意味しますが、改定番号は一意ではありません。ハッシュ（チェンジセットID）は、ファイルの変更と変更履歴の位置に基づいています。完全な40桁の数字は、特定のリビジョンにのみ適用されます。 https://www.mercurial-scm.org/wiki/ChangeSetID –