Question

偶尔会出现一个问题，即确定您上次在Perforce中同步的更改列表的最佳方法是什么。这通常需要通过自动构建系统将更改列表编号注入修订信息。

Answer 1

我建议使用相反的自动构建系统：您应首先使用以下命令从服务器获取最新的更改列表：

p4 changes -s submitted -m1

然后同步到该更改并将其记录在修订信息中。原因如下。虽然Perforce recommends the following用于确定工作空间同步的更改列表：

p4 changes -m1 @clientname

他们注意到了一些问题：

仅当您未从相关工作区提交任何内容时，此方法才有效。
客户端工作空间也可能未同步到任何特定的更改列表。

并且他们没有提到额外的问题：

如果同步发生的最高更改列表严格删除了工作区中的文件，则会报告次高的更改列表（除非它也是严格删除的文件）。

如果您必须先进行同步并稍后进行记录，Perforce建议运行以下命令以确定您是否已被上述问题所困扰;它应该表明没有被同步或删除：

p4 sync -n @changelist_number

Answer 2

我自己回答这个问题，与Jeff建议使用Stackoverflow作为保留技术片段的地方一致....

从命令行使用：

p4 changes -m1 @<clientname>

只需替换为您的客户端规范的名称。这将产生以下形式的输出：

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

可轻松解析以提取更改列表编号。

Answer 3

您可以尝试在“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日柯达信息网/ Ofoto的J.T.Goldstone的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

Answer 4

您也可以使用cstat命令：

p4 help 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'

Answer 5

p4 changes -m1 @clientname这是为我的客户执行此操作的“推荐”方式大约需要10分钟

这就是我使用的：

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

对于同一个客户端需要2.1秒

Answer 6

如果您使用的是P4V，可以用图形方式完成：

在“信息中心”标签（“视图” - >“信息中心”）中选择一个文件夹，您将看到该文件夹尚未更新的更改列表列表。请注意最低编号（在最高行中）。
确保在工作区树中选择了与之前在仪表板中相同的文件夹。然后转到“历史记录”选项卡（“查看” - >“历史记录”）并向下滚动到之前记录的数字。该数字下方的数字是您当前更改列表的编号。

Answer 7

对于严肃的构建（正在准备进行测试），明确指定所需的标签或更改列表编号，同步到标签，并将其嵌入构建工件中。

如果未给出更改列表（或标签），请使用p4 counter change获取当前更改编号，并进行记录。但您仍然需要使用该更改号同步所有内容。

我认为您无法实现您想要的功能，因为通常情况下，整个工作区不会同步到特定的更改列表编号。可以将某些文件显式同步到较旧的版本，然后单个更改列表编号毫无意义。这就是为什么需要一个新的sync来确保单个更改列表编号准确代表代码版本的原因。

关于评论：是的，我的答案是供配置管理员使用，准备构建以提供给QA。我们的开发人员通常不会同步作为构建的一部分;他们在提交之前进行构建 - 这样他们就可以确保他们的更改不会破坏构建或测试。在这种情况下，我们不打算嵌入存储库标签。

通过您的方法，您假设您的整个工作区在上次更改列表提交时已同步到该头，并且该更改列表包含所有打开的文件。在这些假设中容易被误解，难以察觉，并且在时间损失方面非常昂贵。另一方面，解决问题很容易，没有缺点。并且因为可以明确指定更改列表编号，所以您需要的修订版本或代码库的更改速度无关紧要。

Answer 8

对于整个软件仓库（不仅仅是您的工作区/客户端）

p4 counter change

完成工作，只是告诉最后一个更改列表。

Answer 9

到目前为止，我发现的最好的方法是同步到你想要构建的任何更改列表，然后使用更改-m1 //...#have来获取当前的本地更改列表（修订版）。

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

提供您可以在任何地方使用的更改列表编号。我目前正在寻找比p4更改更简单的方法-m1 //...# have。

Answer 10

我不确定你是否得到了你需要的答案，但我遇到了类似的问题。目标是在我们的记录器中写入项目的特定版本。问题是，当我们制作自己的makefile时，整个构建系统由我们的配置管理控制。这意味着所有说“同步到某事然后做某事”的解决方案并不真正起作用，我不想在我们提交时手动更改版本（确定的错误来源）。解决方案（实际上在上面的一些答案中暗示）是这样的：在我们的makefile中，我做p4更改-m1“./...#have” 这样做的结果是用户@客户'msg'更改日期的change_number 我只是将消息创建为由记录器打印的字符串（更改编号是重要元素，但另一个也可用于快速确定某个版本是否包含您自己所做的更改而无需进行检查）。希望这会有所帮助。

确定在Perforce中同步的最后一个更改列表

10 个答案: