О системе контроля версий Perforce Helix

[Bkmz]

Как с ревью перед комитом в Perforce?

Есть ли хуки на клиентской стороне?

[jkeee]

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

Второй вопрос, честно признаюсь, не понял.

[NotSure]

Второй вопрос, видимо, про возможность расширить функциональность клиента.
Например, как в TortoiseSVN

[jkeee]

Я понял, спасибо :).

Есть механизм триггеров, но они исполняются на стороне сервера, не клиента. Это скрипты, которые p4d выполнит перед запросом на какую-то операцию со стороны клиента: коммит, логин, смена пароля, etc.

Это отдельная тема, могу позже написать об этом статью.

[jcmvbkbc]

А есть ли возможность сделать «стек» шелвов, т.е. набор изменений, каждое из которых базируется на предыдущем?

[jkeee]

Пока не могу ответить, надо покопаться в этом направлении.

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

[jcmvbkbc]

Да, так. Это, правда, не самоцель, цель — ревью серии изменений, возможно в перфорсе есть другой идеоматичный способ делать это.

[accipiter]

Нет, такой возможности нет.

[jcmvbkbc]

Понятно. Очень не хватает после гита.

[AllexIn]

Почему нет-то?
Есть зашелвенный файл sample1.txt в CL 1.
Аншелвишь его себе, работаешь, шелвишь в CL 2.
Теперь у тебя в двух CL два разных sample1.txt, но в CL2 он не из мейна, а из CL1.

[Bkmz]

Куда отправить? К сожалению, а может и к счастью приходиться пользоваться p4.
На счет ревью, оно там есть… чисто для галочки. А теперь появляется простейшая вводная, «коммит можно пропустить только после заапрувленного ревью», и вот тут у перфорса начинаются проблемы. Есть нормальные тулы за космические деньги — Code Collaborator от SmartBear. Или вообще ничего, вот прям совсем ничего. Но для того чтобы сделать хоть какой-то вменяемый триггер, который на change-submit будет проверять ( а что проверять? у нас ведь еще нет коммита, мы только хотим его закоммитить. Или даже мы хотим зашелвить чтобы можно было от-ревьюить. А потом этот шелв нужно закоммитить, но при этом чтобы было закрыто ревью), поверьте это ооочень не тривиальное шаманство. И тем кому приходится с этим иметь дело не очень то рады…

А что касается хуков, гугл: «git precommit hooks» и все! Все проблемы решены, и даже проблемы с проверкой ревью перед коммитом!

Я что-то «не очень доволен» этим перфорсом…

[accipiter]

У них есть Helix Swarm. Там ревью перед коммитом вроде бы есть и возможность запретить коммит без ревью тоже есть. Только оно ужасно некачественное. Часто нужно вручную указывать, что коммит уже закоммичен иначе ревью не будет закрыто. Иногда Swarm ошибается и закрывает не то ревью и приходится вручную указывать, что это уже закоммичено, а это — еще нет. Причем такие манипуляции может проделать минимум два модератора, т.к. модератор (администратор тоже) не может одобрять собственные ревью.

[jasper22]

Я полностью согласен с автором статьи Perforce: Fuck you! Если вы прывыкли работать с GIT/ Svn и другими нормальными системами — ни в коем случае не переходите на Perforce. Сэкономьте себе нервы и время. Работа с этий ограмаднейшей кучей хотелок разработчиков, невнятной политикой и видением/пониманиев сабмитов, мерджев и вообщем то каждо дневных действий — тот еще цирк с бубнами. Очень разочаравался в этой программе. Идея «Я художник я так вижу» очень дастает когда ты привык работать по другому (интуитивно). Все в Perforce не интуитивно :( Я так и не понял — то ли дали задание «сделайте не так как у других», то ли сами разработчики перед этом работали грузчиками, не понятно… Я пищу просто предупреждение — если вы привыкли работать с вменяимами системами (как Git, Svn, etc..) ни в коем случае не переходите на Perforce! Подписываюсь под статьей Perforce: Fuck you

[jkeee]

Я, кстати, связывался перед написанием поста с авторами упомянутых мной статей, они не были так категоричны, как вы, и отметили, например, преимущества Helix:
— автоматизация мёржа
— возможность взаимодействовать напрямую из инструментов, с которыми работает команда (IDE, Photoshop, 3DMax, etc.)
+ многие писали о системе в комментариях к статье о выборе СКВ, что меня и подтолкнуло к описанию платформы.
Мне кажется, если бы такая модель workflow не была жизнеспособной, то Helix не был бы популярен :).

Также отмечу, что git не кажется интуитивно понятным человеку, привыкшему работать с SVN, например. Также как чистый p4d кажется вам запутанным. Крутость тут в том, что p4d предоставляет возможность работать в привычной среде (том же git, например), но использовать свой движок.

[semmaxim]

Попробуйте mercurial (TortoiseHg) — как git, только полностью интуитивно понятный.

[boblenin]

Соглашусь с предыдущим оратором. В свое время довелось достаточно пострадать от перфорса. Сложилось впечатление, что авторы продукта надергали всякого (не всегда лучшего) от других систем, а как все это подружить внутри — не подумали. Работать с ним — мучение. Это совсем не гит, это даже не svn по уровню, да что там даже не TFS или (не будь упомянут к ночи) cvs. Perforce хуже чем VSS — потому, что если функционально они очень близки, то VSS хотя бы вменяемый клиент имел.

[A_J]

Верно и обратное: если вы привыкли работать с нормальной системой (P4) то переход на марсианскую (Git), или даже SVN доставит вам много боли.

[Rasifiel]

Отлично работаю с hg и перфорсом. А вот гит ужасен.

[Vanger13]

Как можно работать с VCS, в которой нужно явно checkout'ить каждый файл перед его редактриованием?

[jkeee]

1. Большинство плагинов для IDE автоматически чекаутят файлы.
2. Есть изначальные индикаторы редактирования файлов, те файлы, которые редактирует член команды, отмечены голубой галочкой, мои красной, следовательно я и другие видят сразу же в solution explorer'e/p4v файлы, которые правят коллеги, и это удобнo: когда файлы какие-то критические, то это помогает, чтобы не мёржить важные файлы. (что-то похожее есть в tfs, но там не показывает файлы, которые правят другие, только твои)

[Vanger13]

Уж не знаю кому могут пригодится «индикаторы» в п.2.
У нас дело обстояло так: никто не хочет замарачиваться с чекаутом каждого файла — поэтому p4-git с локальным репозиторием либо плагины для авточекаута (но многие работали без IDE) в итоге сам p4 никто «напрямую» не использовал. И все из-за этой очень мешающей «мелочи».

[zoas]

В таком случае можно редактировать все файлы, а потом использовать Reconcile Offline Work для нахождения всех изменений и делать чекаут одним махом.

[jkeee]

Кстати, ещё вспомнил, что в настройках workspace есть опция writeall, которая позволяет не чекаутить файлы.

[gena_glot]

Понравилась визуализация — как-то никто не вставил чтобы сверху release снзу dev, а так в принципе все то же самое. Работа с прокси в принципе интересная фича но так себе. Статистику везде можно собрать. Непонятно, за что деньги платить.

[Bozaro]

Perforce ужасен: https://bozaro.ru/2016/11/18/p4-broken/

[Javaphite]

Вот и 2019 год клонится к концу, а воз Perforce и ныне там. Несколько рабочих дней упорного изучения и многомесячный опыт коллег сидящих рядом показывает, что дешевле использовать Git-P4 или GitSwarm, чем понять сам Р4 с его периодическими потерями изменений и абсолютно неочевидной логикой работы доброй половины команд.

[accipiter]

Пользуясь Perforce, нужно обязательно делать «Check Out» файла, который хочется изменить. Иначе считается, что файл не изменялся и его можно спокойно перезаписывать. У нас была попытка перехода на Git. К сожалению Git жутко медленный на нашем количестве исходников.