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

Question

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

Answer 1

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

p4 changes -s submitted -m1

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

p4 changes -m1 @clientname

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

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

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

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

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

p4 sync -n @changelist_number

Answer 2

Просто чтобы ответить на это сам в соответствии с предложением Джеффа об использовании 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 основан на коде из Использование P4G.py из командной строки презентация Дж. Т. Голдстоуна, 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

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

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

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

Answer 6

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

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

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

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

Answer 7

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

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

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

---

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

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

Answer 8

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

p4 counter change

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

Answer 9

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

p4 sync @CHANGELIST_NUM p4 меняет -m1 //...#have | awk '{print $ 2}'

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

Answer 10

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