В настоящее время наш магазин dev использует Visual SourceSafe. Мы все знаем, как это может закончиться (плохо), поэтому мы исследуем другие системы. Сначала это Perforce. Кто-нибудь имеет опыт использования и интеграции в Visual Studio (2003/2005/2008)? Насколько он хорош, как любой другой, или он довольно прочный с хорошими функциями, сравнительно?Perforce в магазине Microsoft
Я использовал Perforce на своих последних 3 работах (моя текущая работа Я использую Subversion, что мне не нравится почти так же.) Я большой поклонник Perforce, и, перейдя из SourceSafe, это будет похоже Nirvana. Просто получение атомной проверки будет большим стимулом для вашей компании. В противном случае Perforce быстр, он имеет хорошие инструменты, и рабочий процесс прост для выполнения таких задач, как слияния и интеграция. Я всем сердцем рекомендую. Возможно, это не все новые и яркие, как последние распространенные VCS, но, честно говоря, я предпочитаю модель клиент/сервер для ее скорости, особенно если вы работаете с людьми из других стран, у которых могут быть медленные подключения к вам.
Интеграция с Visual Studio довольно хорошая, но у нее есть несколько раздражающих проблем. Если вы одновременно запускаете другого клиента Perforce (например, P4V), очень сложно отслеживать изменения от другого клиента с точки зрения отображения того, какие файлы в настоящий момент проверяются. Обычно вам нужно закрыть Visual Studio и загрузить проект еще раз, если вы хотите, чтобы он правильно синхронизировался. Но статус синхронизации фактически не влияет на правильность работы проверок/проверок/обновлений, это просто означает, что вас можно обмануть, если вы думаете, что что-то находится в другом состоянии, чем на самом деле, пока вы находитесь в Visual Studio. Клиенты Perforce всегда будут показывать правильный статус, поскольку они постоянно синхронизируются с базой данных.
Кроме того, иногда вы обнаружите, что вам нужно работать «в автономном режиме» (по какой-либо причине он не связан с базой данных Perforce), и когда вы снова загрузите проект, ваши привязки Perforce могут быть потеряны, придется переустанавливать каждый проект по отдельности. Если вы работаете с решением, которое содержит много проектов, это может быть большой болью в patoot. То же самое происходит, когда вы сначала проверяете решение, привязка к Perforce необходима до начала интеграции.
У меня есть опыт использования производного Perforce.
Мне казалось, что с точки зрения администратора трудно справиться, но это было прекрасно использовать с точки зрения программиста.
Опять же, я большой в управлении версией командной строки, поэтому не могу говорить о интеграции VS.
Я не использовал Perforce, но я нашел переход к Team Foundation Server как один из лучших вариантов при работе с Visual Studio.
Perforce отлично работает с Visual Studio, в том числе в режиме «offline», где VS будет записывать ваши локальные файлы и синхронизировать их с сервером позже.
Я стараюсь использовать графический интерфейс Perforce для многих операций (подчиняется, отличается) только потому, что он быстрее/лучше, но процесс проверки IDE происходит без проблем.
Perforce по моему опыту является твердым и лучшим смешанным (code + data) вариантом управления продуктом, если их стоимость не является фактором.
Моя самая большая проблема заключается в том, что производительность сервера под Windows не там, где это так хорошо, как в * nix, и если вы используете сервер * nix, они официально не поддерживают опцию для имен файлов без регистра (что означает вы либо отказываетесь от поддержки, связанной с ошибками файловой системы, либо настраиваете триггер, который запрещает людям добавлять foo.cpp, если существует Foo.cpp).
Другим основным компромиссом является то, что для некоторых общих операций вам необходимо вернуться в командную строку, часто соединяя функции соединения. Одним из примеров будет получение списка файлов в каталоге, который не находится под контролем источника.
Оба эти проблемы, которые больше отражают компанию, чем продукт. ИМО Perforce знает, что они находятся на вершине рынка и, следовательно, не видят причин вкладывать средства в фиксацию таких вещей.
Мы использовали Perforce уже более года, прежде чем переключиться на SVN в последнее время. Хотя мне нравились инструменты (например, визуальный diff и merge и биты администратора), у нас были некоторые очень утомительные проблемы со связыванием, как упоминает Крис; в противном случае интеграция VS удовлетворительна. Во всяком случае, я считаю, что работа с SVN проще и интуитивно понятна, чем Perforce. TortoiseSVN (расширение оболочки Windows Explorer) отлично, и мы купили пару лицензий VisualSVN для интеграции VS. В отличие от Perforce, VisualSVN не работает с интерфейсом MS SCC, а скорее напрямую с клиентом SVN, который я лично вижу в качестве преимущества. У Perforce есть поддержка многих других ОС, но наши не-Windows-разработчики чувствуют себя более комфортно с SVN. Если бы мне пришлось выбирать еще раз, я бы придерживался SVN.
SourceGear Vault - лучший SCM для миграции пользователей VSS.
И его дешево.
Я использовал лично и управлял несколькими командами в течение нескольких лет, которые делали Perforce & Visual Studio. Он работает отлично. Может быть пара привязки/перевязки gotchas, но они, как правило, легко разбираются - Perforce basebase и/или список рассылки - хороший источник информации.
Никогда не возникало проблем с использованием командной строки, визуальных клиентов и VS IDe одновременно - обновление нормально работает нормально.
Мы используем perforce экстенсивно в компании, включая ветвление для очень больших проектов, разработку на Sun Solaris и Windows и более 120 пользователей.
Очень быстро, и Windows GUI (P4V) очень приятный. Интеграция Explorer приемлема. Я отключил интеграцию VS и использовал макросы (например, p4 edit) для редактирования/возврата/разложения файлов. Интеграция VS чрезвычайно раздражает для крупных проектов (наше решение имеет> 130 проектов), но может работать для небольших проектов.
Это трудно назвать $ 900 за пользователяхорошая особенность.