2

私のビルド システムでは、新しいビルドを実行するたびに、現在のコミットのリビジョンとハッシュ情報をいくつかの変数に保存し、ソースで問題なく使用しています。たとえば、ウィンドウのタイトルは「NAME-REVISION-HASH」のようにフォーマットされます。

これの唯一の問題は、コミット情報を含まない標準ソースをダウンロードしてプロジェクトをビルドすることがあり、リビジョンとハッシュがすべて 0 になることです。

これを防ぐために何ができますか？この種の情報を含む別のファイルを追加すると、コミットごとに手動で更新する必要があるため、分散バージョン管理システムを使用する利点が失われます...

DVC を持たない人が正しいリビジョンとハッシュ情報を取得できるようにする方法はありますか?

4

4 に答える 4

1

この種の情報を含む別のファイルを追加すると、分散バージョン管理システムを使用する利点が失われます

なんてこと？「人々は標準ソースをダウンロードしてプロジェクトをビルドします...」VCSがないため、もう1つのファイルは何も「無視」します

コミットごとに手動で更新する必要があるため

そして何？特別に準備されたキーワード (またはテキスト定数) を含む自動コミット ファイルは、少なくとも Mercurial では大きな問題ではありません。

于 2013-03-01T01:35:40.750 に答える
0

別の質問から：

今では、Gitで$ Id：$がサポートされています。ファイルREADMEで有効にするには、 「READMEident 」を.gitattributesに入れます。ファイル名のワイルドカードがサポートされています。詳細については、 mangitattributesを参照してください。

于 2013-03-12T10:21:07.847 に答える
0

Mercurial を使用してアーカイブを生成している場合は、既に処理されています。Web UIのhg archivetarball / zip ダウンロードを実行するコマンドには、.hg_archival.txt次のようなファイルが自動的に含まれます。

repo: 0339f7b37c3416248e4e0b183a481aa40ade150e
node: 0339f7b37c3416248e4e0b183a481aa40ade150e
branch: default
latesttag: null
latesttagdistance: 1

そのため、コードでは、最初にローカル リポジトリをチェックしてバージョン情報を取得し、そこにない場合はファイルを探すロジックを使用でき.hg_archival.txtます。latesttagおよびは、latesttagdistanceリリースにタグを付ける場合に特に便利です。それらを使用して、次のような人間と DVCS の両方に役立つバージョン文字列を作成できます。

2.0.1-5-40ade150e

これは、「40ade150e のハッシュを持つバージョン 2.0.1 以降の 5 つのコミット」と読むことができます。

于 2013-03-01T01:36:12.403 に答える
0

を使用git describeして一意の文字列を取得し、それをビルドに含めることができます。gitそれ自体がバージョンを設定するためにこれを行います (git versionここではgit version 1.8.2.rc1.19.g443d8031.8.2-rc1 + 19 のコミットを返します。最新のコミットは SHA1 443d803e0dacd0a1c6700503689f3cd95751aba1 を持っています; をgit describe返しますv1.8.2-rc1-19-g443d803)。

SCCS の時代から、展開$Id:$やその他のキーワード構造の習慣が生まれました。これは、VCS が個々のファイルを処理するだけだった時代には完全に理にかなっていました。それは今日の痕跡です（そしてgit、「キーワード拡張」はまったく行いません）。

于 2013-03-01T01:11:53.970 に答える