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

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

1> 小智..：

---

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

p4 changes -s submitted -m1

然后同步到该更改并将其记录在修订信息中.原因如下.尽管Perforce建议使用以下内容来确定工作区同步到的更改列表:

p4 changes -m1 @clientname

他们注意到一些问题:

这仅适用于您尚未从相关工作区提交任何内容的情况.

客户端工作空间也可能未同步到任何特定的更改列表.

他们没有提到额外的问题:

如果同步发生的最高更改列表严格从工作区中删除文件,则将报告次高的更改列表(除非它也严格删除文件).

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

p4 sync -n @changelist_number

2> Greg Whitfie..：

---

只是自己回答这个问题,以便与Jeff建议使用Stackoverflow作为保留技术片段的地方....

从命令行使用:

p4 changes -m1 @

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

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

这很容易解析以提取更改列表编号.

3> eel ghEEz..：

---

您可以尝试在"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基于使用P4G.py的代码来自JTGoldstone的命令行演示,柯达信息网/ Ofoto,2005年4月15日.

#! /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

4> 小智..：

---

您还可以使用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'

5> gsf..：

---

p4 changes -m1 @clientname 这是为客户执行的“推荐”方法，大约需要10分钟

这是我用的：

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

同一客户需要2.1秒

---

支持此答案，因为它回答的是实际问题，而不是说“不要那样做”（这是有根据的，但不回答问题）。

6> user31389..：

---

如果您使用P4V,您可以以图形方式执行此操作:

在仪表板选项卡(视图 - >仪表板)中选择一个文件夹,您将看到该文件夹​​尚未更新的更改列表列表.注意最低的数字(在最高行).

确保在工作区树中选择了与仪表板中先前相同的文件夹.然后转到历史记录选项卡(查看 - >历史记录)并向下滚动到之前记录的数字.该数字下方的数字是您当前更改列表的编号.

7> erickson..：

---

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

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

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

---

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

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