Pull to refresh

Comments 27

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

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

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

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

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

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

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

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

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

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

Я что-то «не очень доволен» этим перфорсом…
У них есть Helix Swarm. Там ревью перед коммитом вроде бы есть и возможность запретить коммит без ревью тоже есть. Только оно ужасно некачественное. Часто нужно вручную указывать, что коммит уже закоммичен иначе ревью не будет закрыто. Иногда Swarm ошибается и закрывает не то ревью и приходится вручную указывать, что это уже закоммичено, а это — еще нет. Причем такие манипуляции может проделать минимум два модератора, т.к. модератор (администратор тоже) не может одобрять собственные ревью.
Я полностью согласен с автором статьи Perforce: Fuck you! Если вы прывыкли работать с GIT/ Svn и другими нормальными системами — ни в коем случае не переходите на Perforce. Сэкономьте себе нервы и время. Работа с этий ограмаднейшей кучей хотелок разработчиков, невнятной политикой и видением/пониманиев сабмитов, мерджев и вообщем то каждо дневных действий — тот еще цирк с бубнами. Очень разочаравался в этой программе. Идея «Я художник я так вижу» очень дастает когда ты привык работать по другому (интуитивно). Все в Perforce не интуитивно :( Я так и не понял — то ли дали задание «сделайте не так как у других», то ли сами разработчики перед этом работали грузчиками, не понятно… Я пищу просто предупреждение — если вы привыкли работать с вменяимами системами (как Git, Svn, etc..) ни в коем случае не переходите на Perforce! Подписываюсь под статьей Perforce: Fuck you
Я, кстати, связывался перед написанием поста с авторами упомянутых мной статей, они не были так категоричны, как вы, и отметили, например, преимущества Helix:
— автоматизация мёржа
— возможность взаимодействовать напрямую из инструментов, с которыми работает команда (IDE, Photoshop, 3DMax, etc.)
+ многие писали о системе в комментариях к статье о выборе СКВ, что меня и подтолкнуло к описанию платформы.
Мне кажется, если бы такая модель workflow не была жизнеспособной, то Helix не был бы популярен :).

Также отмечу, что git не кажется интуитивно понятным человеку, привыкшему работать с SVN, например. Также как чистый p4d кажется вам запутанным. Крутость тут в том, что p4d предоставляет возможность работать в привычной среде (том же git, например), но использовать свой движок.
Соглашусь с предыдущим оратором. В свое время довелось достаточно пострадать от перфорса. Сложилось впечатление, что авторы продукта надергали всякого (не всегда лучшего) от других систем, а как все это подружить внутри — не подумали. Работать с ним — мучение. Это совсем не гит, это даже не svn по уровню, да что там даже не TFS или (не будь упомянут к ночи) cvs. Perforce хуже чем VSS — потому, что если функционально они очень близки, то VSS хотя бы вменяемый клиент имел.
Верно и обратное: если вы привыкли работать с нормальной системой (P4) то переход на марсианскую (Git), или даже SVN доставит вам много боли.
Отлично работаю с hg и перфорсом. А вот гит ужасен.
Как можно работать с VCS, в которой нужно явно checkout'ить каждый файл перед его редактриованием?
1. Большинство плагинов для IDE автоматически чекаутят файлы.
2. Есть изначальные индикаторы редактирования файлов, те файлы, которые редактирует член команды, отмечены голубой галочкой, мои красной, следовательно я и другие видят сразу же в solution explorer'e/p4v файлы, которые правят коллеги, и это удобнo: когда файлы какие-то критические, то это помогает, чтобы не мёржить важные файлы. (что-то похожее есть в tfs, но там не показывает файлы, которые правят другие, только твои)
Уж не знаю кому могут пригодится «индикаторы» в п.2.
У нас дело обстояло так: никто не хочет замарачиваться с чекаутом каждого файла — поэтому p4-git с локальным репозиторием либо плагины для авточекаута (но многие работали без IDE) в итоге сам p4 никто «напрямую» не использовал. И все из-за этой очень мешающей «мелочи».
В таком случае можно редактировать все файлы, а потом использовать Reconcile Offline Work для нахождения всех изменений и делать чекаут одним махом.
Кстати, ещё вспомнил, что в настройках workspace есть опция writeall, которая позволяет не чекаутить файлы.
Понравилась визуализация — как-то никто не вставил чтобы сверху release снзу dev, а так в принципе все то же самое. Работа с прокси в принципе интересная фича но так себе. Статистику везде можно собрать. Непонятно, за что деньги платить.
Вот и 2019 год клонится к концу, а воз Perforce и ныне там. Несколько рабочих дней упорного изучения и многомесячный опыт коллег сидящих рядом показывает, что дешевле использовать Git-P4 или GitSwarm, чем понять сам Р4 с его периодическими потерями изменений и абсолютно неочевидной логикой работы доброй половины команд.
Пользуясь Perforce, нужно обязательно делать «Check Out» файла, который хочется изменить. Иначе считается, что файл не изменялся и его можно спокойно перезаписывать. У нас была попытка перехода на Git. К сожалению Git жутко медленный на нашем количестве исходников.
Sign up to leave a comment.

Articles