Выполнить триггер, чтобы запретить отправку неизмененных файлов?

Question

Perforce позволяет людям проверять неизмененные файлы. Почему любая система контроля версий позволила бы это, я не знаю, но это тема для другого вопроса. Я хочу создать триггер, который будет запрещать отправку неизмененных файлов. Однако у меня нет опыта работы с триггерами Perforce. Из того, что я прочитал, я предполагаю, что это будет триггер «Change-content», так как отправляемые файлы должны быть сопоставлены с соответствующими ревизиями заголовков, которые они собираются заменить. Мне нужно было бы перебрать входящие файлы и убедиться, что все они действительно изменились. Проблема в том, что я понятия не имею, как это сделать.

Может ли кто-нибудь с опытом триггера Perforce предложить пример или, по крайней мере, указать мне правильное направление?

Answer 1

В последней версии Perforce разрешить настройку клиента, которая запрещает отправку неизмененных файлов:

    SubmitOptions:  Flags to change submit behaviour.

            submitunchanged           All open files are submitted
            submitunchanged+reopen    (default).

            revertunchanged           Files that have content or type
            revertunchanged+reopen    changes are submitted. Unchanged
                                      files are reverted.

            leaveunchanged            Files that have content or type
            leaveunchanged+reopen     changes are submitted. Unchanged
                                      files are moved to the default
                                      changelist.

                          +reopen     appended to the submit option flag
                                      will cause submitted files to be
                                      reopened on the default changelist.

Это может быть путь для расследования, если пользователь просто проверяет неизмененные файлы из-за апатии.

EDIT:

Учитывая, что вы хотите применить ограничение независимо от настроек рабочего пространства пользователя, вам потребуется триггер, как предлагается в других ответах.

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

Возможно, вы захотите передать% user%, а также% change% плюс, возможно, другие переменные, чтобы вы могли ограничить дорогостоящие операции только для проблемного пользователя.

Answer 2

Вместо того, чтобы использовать триггер, вы можете отредактировать его рабочие пространства (при условии, что у вас есть правильные разрешения) по умолчанию для стратегии отправки, которая избегает этого. По умолчанию (опять же, я не знаю, почему) peforce будет отправлять все выбранные файлы, даже если они не изменены, но это поведение можно изменить. Откройте его рабочие пространства и установите для раскрывающегося списка SubmitOptions значение «revertunchanged», при котором все файлы в списке изменений, которые не были изменены, будут возвращены, или «листья, оставленные без изменений», которые будут сохранять их проверенными, но не отправлять их.

Это также можно сделать при индивидуальной отправке списка изменений, если он хочет просто посмотреть на выпадающий список При отправке.

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

Answer 3

Вы захотите написать триггер изменения содержимого. Эти триггеры запускаются после передачи файлов на сервер, но до их фиксации в БД. Согласно документации на исполнение вы можете использовать команду, аналогичную следующей

p4 diff //depot/path/...@=<change>

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

p4 diff -sr //...@=<change>

Команда -sr сообщит о файлах, которые открываются и совпадают с текущим содержимым депо. Поскольку файлы еще не были зафиксированы, я собираюсь предположить, что вы фактически получите список файлов, содержимое которых было передано на сервер, совпадает с текущей версией заголовка в хранилище. Если p4 diff -sr возвращает одинаковые файлы, возвращает ненулевой код завершения, и отправка будет остановлена, и пользователю придется вручную возвращать свои неизмененные файлы.

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

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

Answer 4

Если вы посмотрите на таблицу «Триггеры» в Perforce, вы увидите, что триггеры - это не что иное, как сценарии, которые вызываются, когда происходит какое-то событие. В вашем случае инициируется событие change-content.

У вас есть несколько вариантов написания сценариев, которые взаимодействуют с Perforce. Страница Perforce для скачивания содержит библиотеки и модули для многих широко используемых языков. Все это поможет вам и значительно упростит то, что вам нужно сделать. Также проверьте страницу документации Perforce и загрузите руководство администратора. Он объяснит, как создать триггер и т. Д.

По сути, вам нужно написать скрипт, который будет получать информацию из отправляемого списка изменений и для каждого файла в нем запускать команду «diff» на сервере. Если вы найдете файл, который не изменился, вам нужно отменить отправку.

Модуль Perforce на вашем любимом языке и руководство администратора предоставят вам все необходимые ответы.

Answer 5

Добавьте это к вашей triggers таблице:

Triggers:
    myTrigger form-in client "sed -i -e s/submitunchanged/leaveunchanged/ %formfile%"

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

Answer 6

У нас есть триггерный скрипт, который начинается с проверки SubmitOptions спецификации клиента на submitunchanged. Если этого нет, то сценарий триггера может завершиться, поскольку пользователь не мог отправить неизмененный файл. В противном случае мы проверяем все файлы, в которых действие редактируется, а тип файла не был изменен. Мы сравниваем такие файлы с предыдущей версией.

Answer 7

Сценарий, приведенный ниже, выполняется в Linux с использованием сценария Perl. Я уверен, что вы можете адаптировать его по мере необходимости в Windows и использовать язык сценариев, отличный от Perl.

В качестве пользователя с правами администратора введите p4 triggers.

Добавьте это в строку Triggers: вашего скрипта.

Trigger_name change-content //... "/<path_to_trigger_script>/<script_name> %changelist% %serverhost% %serverport% %user%"

Trigger_name является произвольным. //... означает все ваши версионные файлы, но вы можете изменить это при необходимости. Все, что окружено %, является специальным именем переменной, уникальным для Perforce, и это будет аргументом вашего скрипта. Это должно быть все, что вам нужно. Обратите внимание, что все, что окружено <>, является переменным и зависит от вашей среды.

Теперь для самого скрипта. Это то, что я написал.

#!/usr/bin/perl

# ----- CHECK 1 : Make sure files NOT identical

# get variables passed in through triggers call 'p4 triggers'
$ChangeNum = $ARGV[0]; #change number
$Server = $ARGV[1];
$Port = $ARGV[2];
$User = $ARGV[3];
$p4 = "<path_to_p4_exec>/p4 -p $Port ";
# get list of files opened under the submitted changelist
@files = `$p4 opened -a -c $ChangeNum | cut -f1 -d"#"`;

# go through each file and compare to predecessor
# although workspace should be configured to not submit unchanged files
# this is an additional check
foreach $file (@files)
{
   chomp($file);
   # get sum of depot file, the #head version
   $depotSum = `$p4 print -q $file\#head | sum`;
   # get sum of the recently submitted file, use @=$ChangeNum to do this
   $clientSum = `$p4 print -q $file\@=$ChangeNum | sum`;

   chomp $depotSum;
   chomp $clientSum;
   # if 2 sums are same, issue error
   if ( $depotSum eq $clientSum )
   {
      # make sure this file is opened for edit and not for add/delete
      if ( `$p4 describe $ChangeNum | grep "edit"` )
      {
         printf "\nFile $file identical to predecessor!";
         exit( 1 );
      }
   }

}