120

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

4

10 に答える 10

94

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

p4 changes -s submitted -m1

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

p4 changes -m1 @clientname

彼らはいくつかの落とし穴に注意しています:

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

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

  • 同期が発生した最上位の変更リストがワークスペースからファイルを厳密に削除した場合、次の上位の変更リストが報告されます (ファイルも厳密に削除されていない限り)。

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

p4 sync -n @changelist_number
于 2008-11-02T03:05:32.907 に答える
30

技術的なスニペットを保持する場所として Stackoverflow を使用するというジェフの提案に沿って、自分でこれに答えるだけです....

コマンドラインから次を使用します。

p4 changes -m1 @<clientname>

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

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

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

于 2008-09-05T22:40:11.000 に答える
16

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

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 は、2005 年 4 月 15 日の Kodak Information Network/Ofoto による JTGoldstone によるUsing P4G.py From the Command Lineプレゼンテーションのコードに基づいています。

#! /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
于 2009-03-21T02:37:01.933 に答える
10

p4 changes -m1 @clientnameこれは、私のクライアントに「推奨される」方法です。所要時間は約 10 分です。

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

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

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

于 2015-10-11T20:14:21.167 に答える
9

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'
于 2012-04-16T22:59:00.513 に答える
5

重大なビルド (テスト用に準備されているもの) の場合、目的のラベルまたは変更リスト番号を明示的に指定し、ラベルに同期して、ビルド アーティファクトに埋め込みます。

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

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

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

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

于 2008-09-05T22:46:09.097 に答える
3

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

p4 counter change

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

于 2012-06-07T18:34:01.597 に答える
2

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

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

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

于 2009-03-26T19:31:39.537 に答える
0

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

于 2013-02-18T14:30:18.637 に答える