На работе мы использовали Visual SourceSafe в течение многих лет, прежде чем переключиться на Perforce в прошлом году. Это определенно дорого, и у нас также есть скрипты сборки Ant, которые выполняются под пользователем «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, посмотреть на график изменений, который показывает историю ветвлений, посмотреть на «временный» вид (очень аккуратная функция - перетащите ползунок вперед и назад по верхней части экрана и просмотрите обновление содержимого файла с каждой ревизией).
Мы только сделали несколько ветвей корелина, так что мы еще не очень опытные с ним. До сих пор это было очень легко, и слияние изменений также довольно легко. В рамках учебного курса все получили экземпляр «Практического перфорса», написанный вице-президентом Perforce по технологиям или некоторым из них. Там довольно много контента о различных методологиях обработки кодовых линий и ветвления. Я думаю, что когда мы использовали SourceSafe, мы были настолько ограничены в том, что он мог сделать, что мы могли только мыслить определенным образом - Perforce гораздо более гибко, что внезапно на самом деле возможно иметь разные философии, когда/how/почему необходимо устанавливать коды и т. д. Поэтому в этом отношении мы все еще много разбираемся в ветвлении и интеграции (слиянии).
P.S. Двухуровневая настройка не требует лицензии и ограничивает только 5 рабочих областей. Вы можете оценить его без ограничения по времени. Они также предлагают бесплатное (но не подкрепленное) лицензирование для проектов с открытым исходным кодом.
Если вы просто хотите логически сгруппированных проверок a.k.a атомных проверок, то почему бы не попробовать svn. –
Мы хотим что-то, что может сделать с ним БОЛЬШЕ, чем просто атомные коммиты. То есть данное исправление проблемы, состоящее из файлов X и т. д., является гражданином первого класса системы –
Я не уверен, что вы получаете там? Вы говорите о работе Perforce? Они - достаточно хороший способ группировки наборов изменений, если вы хотите, - но скорее легкий вес в качестве системы отслеживания дефектов. –