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

117

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

Грег Уитфилд
источник
p4 changes | head -1кажется проще, чем большинство из этих решений.
Шридхар Сарнобат

Ответы:

91

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

p4 changes -s submitted -m1

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

p4 changes -m1 @clientname

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

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

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

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

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

p4 sync -n @changelist_number
Syeberman
источник
Почему «Это работает, только если вы не отправляли ничего из рассматриваемой рабочей области»?
gdw2 05
Если вы отправите изменение, команда «p4 changes -s submit -m1» вернет номер вашего списка изменений. Например, вы синхронизируете со списком изменений 5, ждете пару часов, а затем отправляете список изменений 10. Приведенная выше команда изменений вернет 10.
Ринн
Ссылка мертвая, это была статья? answers.perforce.com/articles/KB/3458/
user31389
Обратите внимание, что вы можете использовать #haveвместо @clientname, что избавляет вас от необходимости искать имя клиентской рабочей области.
йойо
29

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

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

p4 changes -m1 @<clientname>

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

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

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

Грег Уитфилд
источник
Я получаю: запрос слишком большой (более 1500000); см. «p4 help maxresults».
user674669
@ user674669: используйте опцию -m1, которая возвращает только список последних (1) изменений
panako
Это дает информацию о последнем отправленном списке изменений, а не о последнем синхронизированном списке изменений, что и хотелось знать оператору.
Андреас
@marsh Я думаю, что это на самом деле имя клиентской рабочей области, которое по умолчанию соответствует имени компьютера, если не установлено. Смотрите здесь: P4CLIENT .
Андреас Хафербург
15

Вы можете попробовать найти максимальное количество изменений в выводе команды «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
угорь ghEEz
источник
10

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

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

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

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

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

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

GSF
источник
Какое имя у клиента? Как я могу найти эту информацию?
Марш
1
Имя клиента @marsh (или также рабочей области) - это имя объекта perforce, который содержит отображение депо сервера в вашу локальную файловую систему
gsf 01
2
Проголосовать за этот ответ, поскольку он отвечает на фактический вопрос, а не говорит «не делайте этого» (что является допустимым моментом, но не отвечает на вопрос).
Сэм Хосевар 07
1
p4 changes -m1 @clientnameбегать бесконечно ... p4 cstat ...#have | grep change | awk '$3 > x { x = $3 };END { print x }'действительно работает! Спасибо!
simomo
@gsf - спасибо, только что попробовал на моем Linux, и это сработало!
8

Вы также можете использовать команду 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'
gmaghera
источник
5

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

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

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


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

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

Эриксон
источник
Эриксон - хорошее предложение, но я думаю, что оно охватывает несколько иной набор обстоятельств, чем тот ответ, который я дал. Конечно, счетчик будет работать, если у вас, вероятно, будет только головная ревизия, а сервер недостаточно занят, чтобы кто-то, возможно, работающий над другим проектом, не отправил бы запрос между синхронизацией и вызовом счетчика p4. Поэтому я думаю, что ваше предложение, вероятно, лучше всего, когда система сборки выполняет отдельную тягу, а затем сборку. Мой ответ касается случаев, когда синхронизация может быть отделена по времени от сборки. Я думаю, оба варианта действительны в зависимости от обстоятельств.
Грег Уитфилд
3

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

p4 counter change

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


источник
2
Обратите внимание, что это сообщает номер последнего списка изменений депо, ВКЛЮЧАЯ ожидающие (то есть еще не отправленные) списки изменений. Таким образом, любой пользователь, начинающий новую работу в своем клиенте, повлияет на это число. Он будет отличаться от последнего списка изменений, синхронизированного с локальной рабочей областью.
jasonmray
2

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

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

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


источник
0

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

Ассаф Мендельсон
источник