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

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

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

p4 changes -s submitted -m1

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

p4 changes -m1 @clientname

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

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

и есть еще одна ошибка, о которой они не упоминают:

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

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

p4 sync -n @changelist_number

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

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

p4 changes -m1 @<clientname>

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

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

Что легко проанализировать, чтобы извлечь номер списка изменений.

Вы можете попробовать найти максимальное количество изменений в выводе команды «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, Kodak Information Network / Ofoto, 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

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

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

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

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

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

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

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

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