PERFORCEで同期された最後のチェンジリストを決定する

時折発生する質問は、Perforceで最後に同期したチェンジリストを特定する最良の方法は何ですか。これは、自動ビルドシステムによってチェンジリスト番号をリビジョン情報に挿入する場合などに必要になります。

自動ビルドシステムの場合は反対をお勧めします。最初に次のコマンドを使用して、サーバーから最新のチェンジリストを取得する必要があります。

p4 changes -s submitted -m1

次に、その変更に同期して、リビジョン情報に記録します。その理由は以下の通りです。が、PERFORCEは以下のことをお勧めしますワークスペースが同期されているチェンジを決定するために：

p4 changes -m1 @clientname

彼らはいくつかの落とし穴を指摘します：

• これは、問題のワークスペースから何も送信していない場合にのみ機能します。
• また、クライアントワークスペースが特定のチェンジリストに同期されていない可能性もあります。

そして、彼らが言及していない追加の落とし穴があります：

• 同期が発生した最高のチェンジリストがワークスペースから完全に削除されたファイルである場合、次に高いチェンジリストが報告されます（それも、厳密に削除されたファイルでない限り）。

最初に同期して後で記録する必要がある場合は、以下のコマンドを実行して、上記の問題に悩まされていないかどうかを確認することをお勧めします。同期も削除もされていないことを示しているはずです。

p4 sync -n @changelist_number

Stackoverflowをテクニカルスニペットを保持する場所として使用するというJeffの提案に沿って、自分でこれに答えるだけです。

コマンドラインから：

p4 changes -m1 @<clientname>

そして、クライアント仕様の名前に置き換えてください。これにより、次の形式の出力が生成されます。

Change 12345 on 2008/08/21 by joebloggs@mainline-client '....top line of description...'

変更リスト番号を抽出するために簡単に解析されます。

「p4ファイル」コマンドの出力で最大変更番号を見つけてみてください。ただし、作業ディレクトリには同期後のコミットを含めないでください。これは少しだけ良いです

p4 changes -m1 "./...#have"

後者はサーバー上で実行されているように見え、「MaxResults」の制限のために大きなソースツリーでは失敗する可能性があります。

$ p4 changes -m1 "./...#have"
Request too large (over 850000); see 'p4 help maxresults'.

$ p4 -G files "./...#have" | python c:/cygwin/usr/local/bin/p4lastchange.py
Files: 266948
2427657

ここで、p4lastchange.pyは、JTGoldstone、Kodak Information Network / Ofoto、2005年4月15日による、コマンドラインからのP4G.pyの使用のプレゼンテーションからのコードに基づいています。

#! /usr/bin/env python
import sys, os, marshal

if os.name == "nt":
    # Disable newline translation in Windows.  Other operating systems do not
    # translate file contents.
    import msvcrt
    msvcrt.setmode( sys.stdin.fileno(), os.O_BINARY )

lastcl = 0
num = 0
try:
    while 1:
        dict = marshal.load(sys.stdin)
        num = num + 1
        for key in dict.keys():
            # print "%s: %s" % (key,dict[key])
            if key == "change":
                cl = int(dict[key])
                if cl > lastcl:
                    lastcl = cl
except EOFError:
    pass
print "Files: %s" % num
print lastcl

P4Vを使用している場合は、これをグラフィカルに実行できます。

• [ダッシュボード]タブ（[表示]-> [ダッシュボード]）でフォルダーを選択すると、フォルダーがまだ更新されていないチェンジリストのリストが表示されます。（最も高い行の）最小の数値に注意してください。
• ワークスペースツリーで、ダッシュボードで以前と同じフォルダーを選択したことを確認します。次に、[履歴]タブ（[表示]-> [履歴]）に移動し、前にメモした番号までスクロールします。そのすぐ下の番号は、現在のチェンジリストの番号です。

p4 changes -m1 @clientname これは私のクライアントのためにそれを行うための「推奨される」方法です約10分かかります

これは私が使用するものです：

p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'

同じクライアントの場合、2.1秒かかります

cstatコマンドを使用することもできます。

p4ヘルプcstat

cstat -- Dump change/sync status for current client

p4 cstat [files...]

Lists changes that are needed, had or partially synced in the current
client. The output is returned in tagged format, similar to the fstat
command.

The fields that cstat displays are:

    change   changelist number
    status   'have', 'need' or 'partial'

深刻なビルド（テストのために準備されているもの）の場合、目的のラベルまたはチェンジリスト番号を明示的に指定し、ラベルに同期します。て、ビルドアーティファクトに組み込みます。

チェンジリスト（またはラベル）が指定されていない場合は、を使用p4 counter changeして現在の変更番号を取得し、それを記録します。しかし、あなたはまだする必要があります、その変更番号を使用してすべてを同期する。

一般に、ワークスペース全体が特定のチェンジリスト番号に同期されないため、あなたが望むものを正確に達成できるとは思いません。一部のファイルを古いリビジョンに明示的に同期でき、単一のチェンジリスト番号は意味がありません。sync単一のチェンジリスト番号がコードバージョンを正確に表すことを保証するために、フレッシュが必要なのはそのためです。

コメントについて：はい、私の回答は、QAに提供するビルドを準備する構成マネージャーによる使用を目的としています。開発者は通常、ビルドの一部として同期しません。サブミットする前にビルドを行うので、変更によってビルドやテストが中断されないようにすることができます。そのコンテキストでは、リポジトリラベルを埋め込む必要はありません。

このアプローチでは、ワークスペース全体が最後のチェンジリスト送信時にヘッドに同期され、そのチェンジリストには開いているすべてのファイルが含まれていると想定しています。これらの仮定を間違えやすく、検出が難しく、時間のロスという点で恐ろしく高価です。一方、問題の解決は簡単で、欠点はありません。また、チェンジリスト番号を明示的に指定できるため、必要なリビジョンやコードベースの変更の速さは関係ありません。

デポ全体（ワークスペース/クライアントだけでなく）

p4 counter change

最後のチェンジリストに伝えるだけで仕事をします。

私がこれまでに見つけた最良の方法は、ビルドするチェンジリストに同期してから、変更を使用することです-m1 //...#have現在のローカルチェンジリスト（リビジョン）を取得します。

p4 sync @CHANGELIST_NUM p4の変更-m1 //...#have | awk '{print $ 2}'

どこにいても使用できるチェンジリスト番号を提供します。私は現在、p4の変更-m1 //...#haveよりも簡単な方法を探しています。

必要な答えが得られたかどうかはわかりませんが、同様の問題がありました。目標は、プロジェクトの特定のバージョンをロガーに書き込むことでした。問題は、独自のメイクファイルを作成している間、全体のビルドシステムが構成管理によって制御されることでした。つまり、「何かに同期してから何かを実行する」というすべてのソリューションは実際には機能せず、コミットするたびに手動でバージョンを変更したくありません（エラーの確実なソース）。解決策（実際には上記の回答の一部に示されています）は次のとおりです。メイクファイルで、p4の変更を行います-m1 "./...#have"この結果は、change_number on date by user @ client 'です。 msg ' ロガーが出力する文字列にメッセージを作成するだけです（変更番号は重要な要素ですが、他の方法も、特定のバージョンに、確認を強制することなく、自分が行った変更が含まれているかどうかをすばやく判断するのに役立ちます）。お役に立てれば。