Определение последнего списка изменений, синхронизированного с Perforce

Ответ 1

Я рекомендую обратное для автоматических систем сборки: сначала вы должны получить последний список изменений с сервера, используя:

p4 changes -s submitted -m1

затем синхронизируйтесь с этим изменением и запишите его в информации о ревизии. Причина в следующем. Хотя Perforce рекомендует следующее, чтобы определить список изменений, с которым синхронизируется рабочее пространство:

p4 changes -m1 @clientname

они отмечают несколько ошибок:

• Это работает только в том случае, если вы ничего не представили из рассматриваемой рабочей области.
• Также возможно, что рабочее пространство клиента не синхронизируется с каким-либо конкретным списком изменений.

и там есть дополнительная информация, о которой они не упоминают:

• Если самый высокий список изменений, к которому произошла синхронизация, были удалены строго удаленные файлы из рабочей области, будет сообщаться следующий по возрастанию список изменений (кроме случаев, когда они также были строго удалены).

Если вы должны сначала синхронизировать и записать позже, Perforce рекомендует запустить следующую команду, чтобы определить, были ли вы биты вышеупомянутых gotchas; он должен указать, что ничего не было синхронизировано или удалено:

p4 sync -n @changelist_number

Ответ 2

Просто, чтобы ответить на это сам, в соответствии с предложением Джеффа использовать Stackoverflow в качестве места для хранения технических фрагментов....

В командной строке используйте:

p4 changes -m1 @<clientname>

И просто замените имя своей спецификации клиента. Это даст результат формы:

Change 12345 on 2008/08/21 by [email protected] '....top line of description...'

который легко анализируется для извлечения списка изменений.

Ответ 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 основан на коде из Использование P4G.py Из презентации Command Line от JTGoldstone, информационной сети Kodak/Офото, 15 апреля 2005 г.

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

Ответ 5

Для серьезной сборки (готовой к тестированию) явно укажите желаемую метку или номер списка изменений, синхронизацию с меткой и вставьте ее в артефакты сборки.

Если список изменений (или метка) не указан, используйте p4 counter change, чтобы получить текущий номер изменения, и запишите его. Но вам все равно нужно синхронизировать все, используя этот номер изменения.

Я не думаю, что вы можете достичь именно того, чего хотите, потому что в целом все рабочее пространство не синхронизируется с определенным номером списка изменений. Можно явно синхронизировать некоторые файлы с более старыми версиями, а затем один номер списка изменений бессмыслен. Поэтому для обеспечения того, чтобы один номер списка изменений точно отображал версию кода, требуется свежая sync.

Относительно комментариев: Да, мой ответ предназначен для использования менеджерами конфигурации, которые готовят сборку для предоставления QA. Наши разработчики обычно не синхронизируются как часть сборки; они выполняют сборку до отправки &mdash, чтобы они могли убедиться, что их изменения не нарушают сборку или тесты. В этом контексте мы не будем вставлять метки репозитория.

В своем подходе вы делаете предположение о том, что вся ваша рабочая область была синхронизирована с головкой во время вашего последнего списка изменений, и этот список изменений включал все ваши открытые файлы. Слишком легко ошибиться в тех предположениях, которые трудно обнаружить и ужасно дороги с точки зрения потерянного времени. С другой стороны, решить проблему легко, без каких-либо недостатков. И поскольку номер списка изменений может быть явно определен, не имеет значения, какая ревизия вам нужна или как быстро изменяется база кода.

Ответ 6

Для всего склада (а не только для вашего рабочего пространства/клиента)

p4 counter change

выполняет эту работу, просто указывая последний список изменений.

Ответ 7

Лучшее, что я нашел до сих пор, - это сделать вашу синхронизацию с любым списком изменений, который вы хотите построить, а затем использовать изменения -m1//...#have, чтобы получить текущий локальный список изменений (ревизия).

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

Дает вам номер списка изменений, который вы можете использовать везде, где хотите. В настоящее время я ищу более простой способ, чем изменения p4 -m1//...# have.

Ответ 8

p4 changes -m1 @clientname, который является "рекомендуемым" способом сделать это для моего клиента, занимает около 10 минут

это то, что я использую:

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

для одного и того же клиента занимает 2,1 секунды

Ответ 9

Если вы используете P4V, вы можете сделать это графически:

• На вкладке Dashboard (View- > Dashboard) выберите папку, и вы увидите список списков изменений, которые папка еще не обновлена. Обратите внимание на самое низкое число (в самой высокой строке).
• Убедитесь, что в дереве рабочей области вы выбрали ту же папку, что и ранее в панели инструментов. Затем перейдите на вкладку "История" (View- > History) и прокрутите вниз до номера, указанного ранее. Число чуть ниже этого числа - это номер вашего текущего списка изменений.

Ответ 10

Я не уверен, что у вас есть ответ, который вам нужен, но у меня была аналогичная проблема. Цель заключалась в том, чтобы написать в нашем журнале конкретную версию проекта. Проблема заключалась в том, что при создании собственного make файла общая система сборки контролируется нашим управлением конфигурацией. Это означает, что все решения, которые говорят "синхронизировать с чем-то, а затем что-то делать", действительно не работают, и я не хотел вручную изменять версию всякий раз, когда мы совершаем (верный источник ошибок). Решение (которое на самом деле намечено в некоторых из приведенных выше ответов) заключается в следующем: в нашем make файле, я делаю p4 changes -m1 "./...#have" Результатом этого является изменение change_number в дате пользователем @client 'msg' Я просто создаю сообщение в строку, которая печатается регистратором (номер изменения является важным элементом, а другой также полезен для быстрого решения, содержит ли определенная версия изменения, которые, как вы знаете, вы сделали сами, не прибегая к проверке). Надеюсь, это поможет.