Стоит ли Perforce?

Ответ 1

Обновление за ноябрь 2011 года:

Используя Git, поскольку решительно защищенный Tilo, очевидно, лучший выбор для ряд причин (децентрализация, частные коммиты, ветвление, слияние,...).
Я полностью осознаю различия между централизованным и децентрализованным VCS, как описано в "Опишите свой рабочий процесс с помощью управления версиями (VCS или DVCS).

Однако использование его в крупном предприятии непросто.
Я знаю. Я представил Git на крупном предприятии:
Я раскрыл общие причины в Можем ли мы наконец перейти к DVCS в корпоративном программном обеспечении? Является ли SVN еще "обязательным" для разработки? (при этом все еще говорят, что DVCS - очень правильный выбор)

Но я действительно подробно рассказал о главных причинах боли при установке Git на предприятии в разделе Системы управления распределенной версией и Enterprise - хорошее сочетание?".
Я фактически представил эти точки боли в последнем CodeKen 2011 (заменив ex-DevDays 2011).
Презентация была названа " Представляем DVCS в большой корпорации", а твиты были красноречивы:

• Grundlefleck: Мое резюме: не просто Git на корпоративный
• ben_sim: @VonC_ переопределяет боль в # codeken2011: recompiling Git и все его зависимости, чтобы вы могли использовать его производственный сервер на предприятии.

Трюк с DVCS: вам по-прежнему нужен "сервер", централизованное место для всех разработчиков, чтобы получить "благословенную" версию своего репо.
И в крупной корпорации эти взаимные серверы... взаимозависимы, есть еще много других сервисов, что означает, что вы не можете просто добавить свой Git в него (у вас не будет подходящих библиотек на этом сервере).
Кроме того, вам понадобится ваш собственный ssh ​​и httpd для вашего пользователя, чтобы нажать/вывести на/с этого сервера.

Я фактически автоматизировал процесс установки для Git и всех его зависимостей/связанных сервисов в проект GitHub compileEverything.

Итак, да, используйте Git.
На клиентском ПК вы можете установить и начать использовать его за считанные минуты!
Но на сервере крупного предприятия? Это не так просто.

Помните 2009:

• Git поддержка в Windows была возможна, но все еще выполняется,
• Git сам не включал smart http", что означало единственный протокол с аутентификацией для pull/clone и push операций был ssh: убедить пользователей создавать и управлять общедоступными/закрытыми ключами... проблематично, если не сказать больше.
  Https был возможен для pull и clone, даже если запрос был довольно неэффективным. Для push... настройка включала WebDAV и была сложной. Smart Http изменил все это.
• уровни авторизации были неуклюжими (gitosis) и gitolite едва начинался.
  И вам нужен уровень авторизации на большом предприятии.
  Не любой пользователь может получить доступ к любому репозиторию, некоторые из указанных хранилищ вполне конфиденциальны.

Оригинальный ответ, еще в 2009 году:

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

Однако вы должны постоянно синхронизироваться с сервером P4 и должны иметь соответствующую инфраструктуру для поддержки, включая сценарии резервного копирования и DRP: если нет сервера, и вы продолжаете работать, удалив файл, например, он не будет восстановлен при последовательных обновлениях.

Основная жалоба, которую я слышу от команд, использующих ее (так как я занимаюсь только небольшими задачами администрирования на инструменте), есть понятие " Inter- File Branching ", сначала немного запутанная, но очень полезная.

В зависимости от уровня интеграции Усилиями с вашей IDE (здесь затмение) и редакторами основной назойливый аспект будет заключаться в том, чтобы убедиться чтобы синхронизировать рабочее пространство.

Другие интересные ссылки для вас:

• В чем преимущества Perforce?
• В чем преимущества использования Perforce вместо Subversion?

Ответ 2

Perforce - довольно тяжелый вес, особенно для небольшой команды.

Я бы настоятельно рассмотрел SVN или GIT, для хорошего твердого, хорошо поддерживаемого VCS, а затем используйте доступные инструменты и лучшие практики (все, что бесплатно от вашего дружественного локального интернета), чтобы поддерживать нужные функции.

Например, с помощью SVN вы можете настроить свойства "bugtraq", которые помогают сгруппировать изменения. Мы просто вводим идентификатор ошибки с каждой фиксацией bugfix (вы даже получаете хорошее поле ввода для него в формах регистрации в GUI), а затем исправления mutli-commit по-прежнему группируются.

Разумный пост в блоге по этой функции здесь: http://markphip.blogspot.com/2007/01/integrating-subversion-with-your-issue.html

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

Недавно я слышал о вещах о GIT (черт возьми, ребята Spring используют его, и это часто говорит тома), но мы сами находимся в подчинении, поэтому все, что я могу прокомментировать.

Ответ 3

На работе мы использовали Visual SourceSafe в течение многих лет, прежде чем переключиться на Perforce в прошлом году. Это определенно дорого, и у нас также есть скрипты Ant build, запущенные под пользователем "build", который считается одним лицензированным пользователем, который сжигается. Компания заплатила за двухдневный учебный семинар, поэтому разработчики быстро поднялись на скорость, но по-прежнему возникают вопросы, как делать foo и т.д. (Я часть небольшой группы здесь, которая поддерживает других пользователей по проблемам Perforce - в основном из-за того, как работает Visual Studio, а не для Perforce).

С точки зрения использования Perforce, я думаю, что самая большая разница в том, как Perforce концептуализирует всю задачу отслеживания ваших изменений. Например, subversion сохраняет каталог с именем .svn для хранения метаданных о файлах; с p4, сам сервер p4 хранит список файлов, которые у вас есть. Это, по-видимому, самый большой источник проблем - кто-то говорит серверу p4 получать последние файлы для проекта, но затем вручную удаляет что-то. Когда он/она снова запрашивает сервер p4 для последнего, сервер p4 считает, что он/она уже имеет его, поэтому он не обновляется. Когда люди "получат" это, с ним становится намного легче работать. Вам просто нужно сказать серверу "удалить из рабочей области", а затем снова получить его.

У нас есть сочетание пользователей MS Visual Studio, а также Eclipse и IntelliJ, а поддержка плагинов p4 для всех этих функций достаточно хороша. Ежедневная рутина проверки/выхода и получения последних не отличается. В основном мы используем базовые функции, и даже тогда это кажется улучшением по сравнению с Visual SafeSafe (опять же, из объявлений, которые я иногда вижу в сети, вероятно, что-то улучшается по сравнению с Visual SourceSafe). Просто наличие нескольких открытых списков изменений в то же время дает некоторым из нас большую гибкость в том, как мы работаем. Похоже, что настройки плагина Perforce предпочитают тихие проверки, которые сразу заметили многие пользователи, но мне это очень нравится, и я думаю, что в целом это улучшение производительности. В IDE будут выделены имена файлов в другом цвете, поэтому вы можете увидеть, были ли какие-то изменения изменены, а списки изменений p4 всегда показывают, что вы проверили в любом случае.

Слияние изменений, когда несколько пользователей проверили изменения в файле, довольно просто. Инструменты diff не являются супер-зрелищными, но мы можем довольно хорошо сравнивать конфликты по строке и просто щелкаем по тем, что хотим. Я должен отметить, что инструменты gui превосходны. Большинство разработчиков здесь не используют клиент p4v, но некоторые из них и я для него все время используют его. Я упоминал, что инструмент gui превосходный? Вы можете просмотреть все представленные списки изменений, посмотреть историю файлов, перетащить одну ревизию на любую другую ревизию и получить мгновенный diff, посмотреть на график изменений, который показывает историю ветвлений, посмотреть на "временный" вид (очень аккуратная функция - перетащите ползунок вперед и назад по верхней части экрана и просмотрите обновление содержимого файла с каждой ревизией).

Мы только сделали несколько ветвей codeline, так что мы еще не очень хорошо разбираемся в этом. До сих пор это было очень легко, и слияние изменений также довольно легко. В рамках учебного курса все получили экземпляр "Практического опыта", написанный Perforce VP по технологиям или некоторым из них. Там довольно много контента о различных методологиях для обработки кодовых линий и ветвления. Я думаю, что когда мы использовали SourceSafe, мы были настолько ограничены в том, что он мог сделать, что мы могли только думать определенным образом - Perforce настолько более гибкий, что внезапно на самом деле возможно иметь разные философии о том, когда/как/почему кодировки должны быть установлены и т.д. Поэтому в этом отношении мы все еще много разбираемся в ветвлении и интеграции (слиянии).

P.S. Двухуровневая настройка не требует лицензии и ограничивает только 5 рабочих областей. Вы можете оценить его без ограничения по времени. Они также предлагают бесплатное (но неподдерживаемое) лицензирование для проектов с открытым исходным кодом.

Ответ 4

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

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

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

Мы использовали Vault перед Perforce, и все в целом переход был очень плавным без слишком большой потери производительности.:)

Ответ 5

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

С другой стороны, я недавно рассматривал некоторые распределенные системы управления версиями (git, Mercurial и Bazaar, в частности). У них много функций, которые выглядят очень интригующими, особенно не требуя постоянного подключения к серверу. Кроме того, вы можете настроить свою систему на "основной" сервер, даже с распределенными системами. Поэтому я бы предложил сначала взглянуть на одну из них и посмотреть, соответствуют ли они вашим потребностям.

Ответ 6

Этот вопрос похож по своему характеру на то, что Ant лучше, чем Maven или С#, лучше, чем Java. На мнения людей будут влиять их шрамы в битвах, и у большинства людей есть только тяжелый, полезный опыт от 1 до 3 инструментов SCM, поэтому вы не можете дать сбалансированное мнение.

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

Не помешало бы попробовать Subversion, Git, Mercurial или один из других SCM с открытым исходным кодом какое-то время? Если окажется, что они не подходят для цели, по крайней мере, это даст вам представление о том, что нужно искать при оценке Perforce.

Ответ 7

Большинство преимуществ Perforce также доступны в Subversion. Subversion также проще в управлении и не имеет столь жесткого требования оставаться подключенным к серверу.

Однако я считаю, что синтаксис p4 намного проще в использовании, а вывод гораздо менее загадочный, чем svn.

Ответ 8

Я работал с svn, cvs, vss, и теперь я работаю с perforce. Я использую для работы с baazar свои личные проекты, и я пробовал git и mercurial.

Я не рекомендую вам вообще заниматься, и, конечно же, я не рекомендую вам VSS. Это небезопасно, ненадежно и непрактично работать. Он моделирует ее гораздо более скрученную, чем svn, cvs, git и т.д. Также сложнее использовать сценарии (так как вам приходится иметь дело с представлениями, клиентами и другими системными переменными).

Я бы порекомендовал вам svn с любым обычным трекером. Вы можете настроить его через svn hooks по желанию.... В некоторых случаях было бы интересно разойтись (git, mercurial, baazar), но если у вас еще нет мнения, вы должны начать с svn..

ну, это мое мнение, конечно...

Ответ 9

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

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

Ответ 10

Год 2011

Короткий ответ: Нет! Используйте Git!

В прошлом я использовал и администрировал CVS и Perforce в крупных компаниях (~ 2000 человек) в течение нескольких лет. Я бы настоятельно рекомендовал использовать Git over Perforce в любой день - даже в корпоративной среде. Исходя из CVS, потребовалось некоторое время, чтобы понять "способ Git", но через короткое время, используя его, становится ясно, насколько превосходит его парадигма.

Крупные компании, такие как Sun Microsystems, продемонстрировали еще в 2006 году, как выгодно использовать переход от централизованных систем управления версиями (CVS) к распределенным системам контроля версий (Mercurial).

IMHO Perforce - это, в основном, модифицированный CVS, который был запутан и сложен до такой степени, что чрезвычайно тяжело (и медленнее) использовать, и вам понадобится помощь их отдела обслуживания, чтобы все было сделано. Он сконструирован таким образом, что вам понадобится их сервисный отдел в какой-то момент или другой (например, когда вы пытаетесь автоматизировать процессы вокруг него). О, и лицензии действительно дороги! Почему вы хотите использовать такой продукт? Perforce действительно хорош для обеспечения безопасности своих администраторов, хотя: -)

Git, с другой стороны, представляет собой децентрализованную систему управления версиями (VCS), которая гораздо более подходит для работы разработчиков. Они могут легко создавать локальные (отбрасываемые) ветки, для разработки функций или исправления ошибок, и сохранять этот код локально под управлением версий, а затем при необходимости слить его обратно в публичный репозиторий. Их временные ветки не загрязняют проект. Если есть хранитель ворот, они могут попросить их внести изменения, или если есть публичный репозиторий, они могут легко объединить свои локальные изменения кода в него. Слияние или создание Diff - очень частая работа для разработчиков (!) И супер-быстро с Git. Кроме того, Git очень надежный и легко обнаруживает повреждения диска (поскольку он использует контрольные суммы SHA1).

Проект ядра LINUX использует Git очень успешно! Проверьте этот разговор и пропустите минутку 16..25, где Linux Torvalds упоминает Perforce: http://vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git

Долгий ответ:

Программное обеспечение развивается, также как и системы контроля версий (VCS). С тех пор, как Perforce был создан, многое было усвоено. В 1990 году мантра систем контроля версий должна была иметь централизованную систему, которая обрабатывает все программные проекты внутри компании. Весь исходный код и ветки в одном центральном месте... Это оказалось не только сложным и дорогостоящим для администрирования, но также показало некоторые огромные недостатки:

• простое требование для VCS состоит в том, что если вы помещаете файл в репозиторий, вы получаете тот же файл с теми же разрешениями, что и без изменений. С Perforce или CVS это не так.

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

• ветвление в централизованных системах управления версиями - это, как правило, огромная боль

  • создание новых ветвей происходит медленно, требует и администрирует, и блокирует систему контроля версий (в случае Perforce или CVS: от нескольких минут до часа! жаль, что вы не можете зарегистрировать, мы создаем новую ветку...)
  • в общих ветвях отображаются глобально, что означает, что вам нужны хорошие соглашения об именах, и что люди, как правило, неохотно создают новые ветки (чтобы предотвратить "ветвление" ) - все же результат всегда путаница ветвей.

• локальная разработка выполняется вне системы управления версиями, а код проверяется только после того, как она "стабильная" (это само по себе делает недействительным наличие VCS в первую очередь, потому что разработчики могут потерять несколько дней работы, если их локальный диск падает)

• разработчики не могут просто создать локальную ветвь для разработки новой функции и не обнаруживать ее в централизованном VCS

• проблемы обычно возникают, когда компания пытается использовать свои "централизованные" VCS в нескольких географических точках (это определенно вызывает проблемы и боль с Perforce)

• администратор централизованного VCS становится узким местом

• централизованная модель означает удар производительности, даже для простой вещи, такой как diff, потому что все подразумевает сетевую операцию

• вы не можете работать в автономном режиме

• люди должны иметь фиксацию доступа к коду регистрации

• Слияние с Perforce или CVS утомительно, требует много времени и, следовательно, дорого!... и очень частое задание, которое разработчики должны делать!

Ответ 11

слушать linus: http://vodpod.com/watch/65074-tech-talk-linus-torvalds-on-git

Ответ 12

Плагин P4Eclipse Perforce для Eclipse имеет команду Team → Create Patch, как описано здесь:

http://www.perforce.com/perforce/doc.current/manuals/p4eclipse/topics/patch.html

Если вы хотите поместить свои пальцы в воду, Perforce имеет бесплатное издание на 20 человек, которое вы можете протестировать с бесплатной поддержкой:

http://www.perforce.com/downloads/Perforce/20-User

Чтобы создать исправления через командную строку в Perforce, вы можете запустить 'p4 diff2 -u' для создания патч-совместимого вывода, но изменения должны быть представлены уже.

Чтобы обрабатывать создание патчей в Perforce через P4V, вы можете отложить ожидающий список изменений в одном рабочем пространстве, а затем удалить его в другом. Вот сообщение в блоге с полками в действии:

http://www.perforce.com/blog/130304/light-code-review-shelving

Надеюсь, вы найдете то, что ищете, что бы вы ни решили.