Когда более 2-х лет назад был презентован Git as Subversion, некоторые люди активно предлагали попробовать Perforce.

И вот, волей судеб, последние полгода на работе проект живёт в Perforce. И у меня сложилось о нём своё мнение.

Архитектура и безопасность

Для подключения к серверу ему нужно знать только адрес сервера (P4PORT), имя пользователя (P4USER) и имя рабочей копии (P4CLIENT). Вся остальная информация хранится на сервере.

При этом клиент глуп и вся логика команд так же находится на сервере. Для выполнения любой команды клиент выполняет примерно следующую последовательность действий:

• Подключиться к серверу и сообщает кратенькую информацию о себе;
• Говорит серверу, какую команду и с какими аргументами от него хочет выполнить пользователь;
• Ждет от сервера набор инструкций и выполняет их.

Кстати, список полей для формы ввода информации о changelist-е и тому подобное, так же присылается с сервера.

Особенно хочу акцентировать внимание, что для клиента команды p4 help и p4 submit ничем внутренне не отличаются. И в случае подмены Perforce-сервера злоумышленник получает массу возможностей по модификации файлов на машине клиента (в том числе и за пределами рабочей копии).

Если не используется SSL-подключение, то клиент не обратит никакого внимание на подмену сервера.

Общие впечатления

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

• Очень быстрое получение версии с сервера в первый раз;
• Никакие служебные данных не занимают место на клиентской машине.

И свои минусы:

• Клиент не может ничего сделать без взаимодействия с сервером;
• На клиенте нет способа дешево узнать состояние файлов и находятся ли они под контролем версий;
• Любое изменение рабочей копии в обход Perforce-утилит нарушает соответствие реального содержимого директории и состояния о котором знает сервер.

В итоге, к примеру:

• Нет способа быстро получить чистую рабочую копию (git reset --hard && git clean -fdx).
• Нет способа быстро получить список измененных без p4 open файлов.

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

Можно возразить, что в Perforce есть режим сравнения файлов, основанный на дате модификации KB-3097, но этот режим порождает дополнительные проблемы:

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

Распреденность

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

Сидя в Москве нельзя использовать сервер, расположенный в Калифорнии: любое действие, требующее передачи данных туда-обратно становится чудовищно медленным.

Есть два выхода из данной ситуации:

• Perforce Proxy - простая кэширующая прокся, позволяющая не бегать каждому пользователю за файлами на другую сторону земного шара. Самостоятельно действовать не способна, но за то может быть настроена без вмешательства в конфигурацию центрального Perforce-севера.
• Perforce Edge Server - относительно самостоятельный вариант Perforce-реплики, который позволяет значительную часть операций производить локально. Но те не менее часть операций (submit, создание changelist-а) все равно выполняется на основном сервере.

С Perforce Edge Server-ом можно жить относительно комфортно:

• Остаются проблемы с долгим вытаскиванием файлов, которые по каким-то причинам не дошли до Edge Server-а;
• Любая операция по отправке данных на сервер по прежнему использует основной сервер и вызывает боль.

Кстати, клиент всегда отображает время во временной зоне сервера. Это очень удобно. Пруф:

Date and time specifications are always interpreted in terms of the local time zone of the Perforce server.

Кроссплатформенность

Perfoce работает как под Windows, так и под Linux. Но упоси Господь вас попытаться использовать сервер под одной операционной системой, а клиента под другой KB-3081:

• UNIX server + UNIX clients
  No problem -- Case of the Perforce meta-data and archive files are always consistent.
• Windows server + Windows clients
  No problem -- Case differences can exist between meta-data and archives files, however, these differences are ignored.
• UNIX server + Windows clients
  Potential problem -- The Perforce Server on UNIX (and the UNIX file system) can store case-variant files; the Windows file system cannot store case-variant files.
• Windows server + UNIX clients
  Potential problem -- The Perforce Server on Windows can maintain case-variant meta-data. As a result, files that exist in one directory on a Windows-based Perforce Server might appear as two or more case-variant directories in a UNIX-based Perforce client workspace.

Примерно похожая проблема с кодировками KB-3106: по умолчанию Perforce использует 8-ми битную кодировку и предполагается, что она у всех одинаковая.

Можно на сервере включить поддержку Unicode, но:

• Эта дорога в один конец и отменить эту операцию нельзя;
• Если кто-то залил данные за пределами ASCII, то use any editor or process to remove or convert non-UTF8 byte sequences to be a valid UTF8 byte sequence, Luke. И в случае с именами файлов это не выглядит тривиальной задачей.

Stream-ы

Perforce Streams

Perforce streams are "branches with brains," a containerized approach to managing bodies of related files such as codelines.

Когда я слышу, что Streams, это умные ветки, я вспоминаю картинку с умным молотком. Может оно и звучит круто, но свою функцию выполнять перестаёт.

Основная претензия к Stream-ам: они существуют отдельно за пределами версионирования. То есть, если у вас есть Stream со стабильной версией, то никаких гарантий, что кто-то не поменяет его задним числом просто нет.

При этом, для того, чтобы создать Task Stream, я должен:

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

Отдельное удовольствие доставляет конфликты в тысячах файлов при мерже одного стрима в другой.

Юзабилити

Порождение Сатаны

Это скорее к курьёзами, но помимо порта по-умолчанию (1666), для шифрования пользовательских данных Perforce использует шифр Lucifer. Мне кажется, это не спроста…