К чему преимущества По необходимости?

Я работал с По необходимости в течение многих лет, а также Clearcase, Sourcesafe, RCS, PVCS, CVS и Подрывной деятельности. Позже я начал использовать МЕРЗАВЦА также.

На основе этого опыта мое мнение - то, что, в большинстве целей, По необходимости лучшая система управления версиями для коммерческих сред. В то время как не столь простой, первоначально, как Подрывная деятельность, это имеет много более мощных функций, особенно вокруг ветвления и слияния. "Блокировка" подходом по умолчанию обычно больше подходит для этой среды.

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

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

Для многих случаев, где Подрывная деятельность превосходит По необходимости многих людей, кажется, предпочитают распределенные системы как МЕРЗАВЕЦ, Базар, Подвижный, в эти дни. Из того, что я видел МЕРЗАВЦА, они могут быть правы, и я уверен, что другие плакаты подтвердят это.

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

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

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

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

, В целом, различия с другим SCM's не очень огромны. Вы встречаетесь По необходимости во многих местах, потому что за один раз это был один из некоторых (если не единственное) частично достойный SCM, который работал над Windows и Mac

, Если я не ошибаюсь, можно использовать его бесплатно с ограниченным количеством клиентов, таким образом, можно испытать его без большого количества боли...

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

я работал с SVN прежде (через Черепаху SVN) и нашел его намного более простым и дружественным.

, Конечно, все это с пользовательской точки зрения, вероятно, SCMs имеют другую точку зрения

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

я нахожу систему Perforce с "changelists", та группа изменения в нескольких файлах и рассматриваю их как единицу, хорошую. Я уверен, что можно сделать что-то similiar с SVN, но это не столь легко из поля.

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

Мы используем По необходимости на работе и в то время как у меня есть небольшой опыт с различным программным обеспечением SCM, я нахожу этого вполне хорошо сделанным, с хорошим GUI (в Windows), хорошая поддержка командной строки, партия хороших функций... Мог бы требовать времени для привыкания к его логике, но это, вероятно, верно для большей части SCM, я думаю.

Я соглашаюсь с предыдущим Yuval - работавший с По необходимости и svn, и в GUI и в режиме командной строки, я предпочитаю svn. Однако компания, на которую я работал, в то время, когда переключено со свободного cvs, для которого она использовала По необходимости. Его GUI более роскошен. Я думаю, что его модель фиксации отличается - это использует блокировку, которая может быть предпочтительна для некоторых разработчиков/менеджеров. В коммерческой установке, имея людей поддержки для Вашего инструмента управления версиями может помочь также. Я услышал, что в некоторых крупных компаниях с помощью открытого исходного кода в продуктивных средах запрещается, потому что они хотят быть в состоянии получить поддержку каждой строки кода.

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

Perforce, возможно, самая централизованная система SCM, которую я когда-либо использовал. Представьте, что они гордятся тем, что ничего не кэшируют на вашем диске. Выполнение синхронизации раздражает, потому что в огромном количестве случаев она ничего не сделает, если вы не выполните принудительную синхронизацию - а принудительная синхронизация копирует все с сервера обратно вам - если ваш проект составляет 10 ГБ, он скопирует все из них .

У меня есть предыдущий опыт использования SourceSafe, CVS, SVN, Mercurial и git (меньше двух последних).

Я думаю, что большинство SCM с открытым исходным кодом являются зрелыми, и вы можете выбрать один из. Если вам нужно что-то централизованное, перейдите на SVN, а если вы хотите что-то децентрализованное, используйте Mercurial (у меня был плохой опыт работы с git в Windows).

Некоторые другие проблемы, которые у меня были с необходимостью:

• то, что вы фиксируете, не то, что вы получаете обратно : например, если вы фиксируете файл UTF16 на Intel Mac и синхронизируете его с другим Mac PPC, вы получите другой файл UTF16, потому что perforce умен и скрывает вас от файла в клиентском порядке байтов. UTF16-BE - UTF16-LE?!
• по необходимости создавать сценарии в 10 раз сложнее, чем другие инструменты.
• если вы начнете использовать его и привяжете к своим процессам с помощью сценариев, вероятно, вы умрете с ним, потому что все делается в perforce way и perforce way: (
• image, что очень легко отключить сервер p4: просто выполните синхронизацию в корне проекта. Там, где я работаю, это запрещено, потому что это может снизить подачу! Существует сценарий наблюдения, который отслеживает процессы сервера perforce, и если один из них занимает x ГБ ОЗУ, он убивает его и отправляет вам уведомление. Да, выполнение одной простой команды на клиенте может создать процесс размером 3 ГБ на сервере за 5-10 секунд.