Добрейшего.
Как уже писал чуть ранее, я по роду деятельности после смены места работы активно осваиваю новое пианино - Perforce. Часто его сокращённо называют P4.
До этого на Перфорс доводилось только глядеть через плечо коллег, работавших с ним на небольшом проекте. Так что, можно сказать, знакомство начал с чистого листа. Почитал материалы тренинга и по ходу дела смотрел доки на сайте самого Перфорса.
Общие основы
Perforce - типичная централизованная система контроля версий. Есть сервер, который хранит историю изменений подконтрольных сущностей в репозиториях, которые называются depot. Читается как "дипоу", но вообще - просто депо, типа как трамвайное. Клиент, подключаясь к серверу, берет нужную часть сущностей к себе на локальную машину. С этого момента программа-клиент П4 создает т.н. workspace, т.е. рабочее пространство.
Все изменения, вносимые в workspace, при желании отправляются на сервер, в соответствующее депо. Процесс отправки называется традиционно - submit. Отправляемые изменения - атомарны, и работа идет посредством change lists, т.е. списков изменений, отправляемых единой транзакцией. Изменил десяток файлов - посылаешь их через сабмит. Если что-то пошло не так - всё изменение откатывается.
Списки имеют каждый свой номер - примерно как в SVN есть сквозные номера ревизий. Создавая новый список, ему можно или самому присвоить очередной номер, или не присваивать и при сабмите это сделает сам Перфорс.
Если нет желания засабмитить изменения, но нужно показать результат работы кому-либо - используется механизм shelving. Нужные файлы выкладываются "на отдельную полку" всем причастным, их просматривают, делают правки и берут обратно. Похожий механизм используется в Microsoft TFS.
Работа ведется в основном в GUI-оболочке, P4V. Однако можно использовать и командную строку. Но P4V достаточно удобен, отторжения и неудобств он не вызывает.
Что касается обеспечения распределённости разработки и балансировки нагрузки, то несколько серверов могут быть реплицированы между собой. Можно спокойно работать с прокси-сервером и новые изменения будут доступны всем серверам по мере обмена данными между ними. В ClearCase аналогом является механизм MultiSite.
File mappings
Первая особенность Перфорса от большинства систем контроля версий - использование для связи структуры файлов в depot и их отображения на структуру директорий механизма file mapping. Т.е. это отображение файлов из депо на файловую систему пользователя.
Например, рабочее окружение под названием my_workspace настроено в директорию C:\workspaces\my_workspace\ . В настройках workspace пишется например такое:
//depot/... //my_workspace/...
Это означает, что структура будет отображена один-к-одному. Теперь достаточно взять последние версии файлов отдельной командой - и в директории на диске появится срез исходников.
Можно также комбинировать файлы из разных источников. Например, если есть депо с исходниками двух модулей - //depot1/module1 и //depot2/module2, а также приложение, которое их использует - //app_depot/main/, то соорудив вот такие правила
//depot1/module1/... //my_workspace/modules/module1/...
//depot2/module2/... //my_workspace/modules/module2/...
//app_depot/main/... //my_workspace/main/...
можно получать срез нужных исходников автоматически в нужной структуре директорий.
Есть ещё несколько возможностей, связанных с mapping, но общий смысл - именно такой.
Ветвление, слияние и метки
Модель ветвления похожа на модель Subversion. Как и в SVN, здесь ветка образуется копированием структуры нужной директории в любое место депо. Лично мне такой подход не нравится по принципиальным соображениям, однако - он вот такой. В работе столкнулся с тем, что хотя образование ветки процесс быстрый (работает cheap copy), получается всё равно довольно громоздко, т.к. для отстройки исходников файлы приходится всё равно доставать из депо в полном составе. При количестве файлов в ветке, исчисляемом тысячами, процесс растягивается на долгие минуты и даже, при плохой связи, на часы.
При этом, в отличие от Сабвершна, метки там - это действительно метки. То есть метка - это бирка, которая вешается на нужную версию выбранного файла. Т.е. вешая метку на какую-то директорию в какой-то момент времени, пользователь помечает видимые версии каждого файла внутри директории нужной информацией. И при необходимости по этой метке можно воссоздать нужный срез исходников. Есть и побочный эффект, которого я не встречал нигде больше - меткой можно пометить одновременно два ответвления файловой структуры. Я пока не видел как бы это могло кому-то понадобиться, но в других системах это в принципе невозможно. Занятно, в общем.
Для удобства интеграции механизм mapping, описанный выше, был расширен не только для взятия файлов из депо, но и для ветвления и выставления меток. Например, если часто делается интеграция с ветки для новой фичи на основную ветвь разработки, то создается mapping, где прописываются оба бранча, и дальнейшая интеграция сводится к паре кликов. Аналогично - с метками.
Что касается слияния, то как и SVN, Перфорс не блещет ни скоростью, ни сообразительностью. Да, оно успешно сливает вместе две ветки с общим предком. Даже использует для этого 3-хстороннее слияние, т.е. определяет общего предка. При этом скорость при работе с файлами размером в несколько десятков Кб и 2-3-хгодичной историей весьма низка, бывает до десятка секунд. Дефолтный инструмент сравнения и слияния, при всей и наглядности и удобстве, при сложных сравнениях просто начинает выдавать несуразицу, например совершенно не сращивает перемещение кода по файлу. Перемещение и переименование файлов отрабатывает иногда как перемещение, а иногда - как удаление и создание нового файла. Изменения между такими файлами, которые в одной ветке переименованы, а в другой - остались на месте, практически не отслеживаются вообще.
Допускаю, что у меня были сложные нетривиальные случаи - история у многих файлов очень большая и разветвлённая - но конкретно для меня слияние оказалось не очень предсказуемым и стабильным функционалом.
Управление доступом
Что откровенно порадовало - так это управление доступом.
Для удобства все пользователи могут разбиться по группам. У каждого юзера или группы могут быть права разных уровней - от полного отказа в доступе до полных прав, включая запись или создание ветки. В общем, вполне стандартные возможности.
Сами же права прописываются в виде текста, где перечисляются права на доступ, имя юзера или группы, IP-адрес или диапазон, для которого применимы права, и директория, на которые права прописываются (wildcards также применимы). Чем ниже правило, тем оно приоритетнее.
Простая схема, но она даёт все возможности для гибкого управления доступом.
Общее впечатление
Общее впечатление сейчас скорее положительное, несмотря на некоторые неудобства. Я бы сказал, что Perforce - это по сути сильно улучшенный Subversion с хорошим GUI. Но при этом платный.
По мере погружения в глубины Перфорса, наверное, что-то ещё напишу.
Как уже писал чуть ранее, я по роду деятельности после смены места работы активно осваиваю новое пианино - Perforce. Часто его сокращённо называют P4.
До этого на Перфорс доводилось только глядеть через плечо коллег, работавших с ним на небольшом проекте. Так что, можно сказать, знакомство начал с чистого листа. Почитал материалы тренинга и по ходу дела смотрел доки на сайте самого Перфорса.
Общие основы
Perforce - типичная централизованная система контроля версий. Есть сервер, который хранит историю изменений подконтрольных сущностей в репозиториях, которые называются depot. Читается как "дипоу", но вообще - просто депо, типа как трамвайное. Клиент, подключаясь к серверу, берет нужную часть сущностей к себе на локальную машину. С этого момента программа-клиент П4 создает т.н. workspace, т.е. рабочее пространство.
Все изменения, вносимые в workspace, при желании отправляются на сервер, в соответствующее депо. Процесс отправки называется традиционно - submit. Отправляемые изменения - атомарны, и работа идет посредством change lists, т.е. списков изменений, отправляемых единой транзакцией. Изменил десяток файлов - посылаешь их через сабмит. Если что-то пошло не так - всё изменение откатывается.
Списки имеют каждый свой номер - примерно как в SVN есть сквозные номера ревизий. Создавая новый список, ему можно или самому присвоить очередной номер, или не присваивать и при сабмите это сделает сам Перфорс.
Если нет желания засабмитить изменения, но нужно показать результат работы кому-либо - используется механизм shelving. Нужные файлы выкладываются "на отдельную полку" всем причастным, их просматривают, делают правки и берут обратно. Похожий механизм используется в Microsoft TFS.
Работа ведется в основном в GUI-оболочке, P4V. Однако можно использовать и командную строку. Но P4V достаточно удобен, отторжения и неудобств он не вызывает.
Что касается обеспечения распределённости разработки и балансировки нагрузки, то несколько серверов могут быть реплицированы между собой. Можно спокойно работать с прокси-сервером и новые изменения будут доступны всем серверам по мере обмена данными между ними. В ClearCase аналогом является механизм MultiSite.
File mappings
Первая особенность Перфорса от большинства систем контроля версий - использование для связи структуры файлов в depot и их отображения на структуру директорий механизма file mapping. Т.е. это отображение файлов из депо на файловую систему пользователя.
Например, рабочее окружение под названием my_workspace настроено в директорию C:\workspaces\my_workspace\ . В настройках workspace пишется например такое:
//depot/... //my_workspace/...
Это означает, что структура будет отображена один-к-одному. Теперь достаточно взять последние версии файлов отдельной командой - и в директории на диске появится срез исходников.
Можно также комбинировать файлы из разных источников. Например, если есть депо с исходниками двух модулей - //depot1/module1 и //depot2/module2, а также приложение, которое их использует - //app_depot/main/, то соорудив вот такие правила
//depot1/module1/... //my_workspace/modules/module1/...
//depot2/module2/... //my_workspace/modules/module2/...
//app_depot/main/... //my_workspace/main/...
можно получать срез нужных исходников автоматически в нужной структуре директорий.
Есть ещё несколько возможностей, связанных с mapping, но общий смысл - именно такой.
Ветвление, слияние и метки
Модель ветвления похожа на модель Subversion. Как и в SVN, здесь ветка образуется копированием структуры нужной директории в любое место депо. Лично мне такой подход не нравится по принципиальным соображениям, однако - он вот такой. В работе столкнулся с тем, что хотя образование ветки процесс быстрый (работает cheap copy), получается всё равно довольно громоздко, т.к. для отстройки исходников файлы приходится всё равно доставать из депо в полном составе. При количестве файлов в ветке, исчисляемом тысячами, процесс растягивается на долгие минуты и даже, при плохой связи, на часы.
При этом, в отличие от Сабвершна, метки там - это действительно метки. То есть метка - это бирка, которая вешается на нужную версию выбранного файла. Т.е. вешая метку на какую-то директорию в какой-то момент времени, пользователь помечает видимые версии каждого файла внутри директории нужной информацией. И при необходимости по этой метке можно воссоздать нужный срез исходников. Есть и побочный эффект, которого я не встречал нигде больше - меткой можно пометить одновременно два ответвления файловой структуры. Я пока не видел как бы это могло кому-то понадобиться, но в других системах это в принципе невозможно. Занятно, в общем.
Для удобства интеграции механизм mapping, описанный выше, был расширен не только для взятия файлов из депо, но и для ветвления и выставления меток. Например, если часто делается интеграция с ветки для новой фичи на основную ветвь разработки, то создается mapping, где прописываются оба бранча, и дальнейшая интеграция сводится к паре кликов. Аналогично - с метками.
Что касается слияния, то как и SVN, Перфорс не блещет ни скоростью, ни сообразительностью. Да, оно успешно сливает вместе две ветки с общим предком. Даже использует для этого 3-хстороннее слияние, т.е. определяет общего предка. При этом скорость при работе с файлами размером в несколько десятков Кб и 2-3-хгодичной историей весьма низка, бывает до десятка секунд. Дефолтный инструмент сравнения и слияния, при всей и наглядности и удобстве, при сложных сравнениях просто начинает выдавать несуразицу, например совершенно не сращивает перемещение кода по файлу. Перемещение и переименование файлов отрабатывает иногда как перемещение, а иногда - как удаление и создание нового файла. Изменения между такими файлами, которые в одной ветке переименованы, а в другой - остались на месте, практически не отслеживаются вообще.
Допускаю, что у меня были сложные нетривиальные случаи - история у многих файлов очень большая и разветвлённая - но конкретно для меня слияние оказалось не очень предсказуемым и стабильным функционалом.
Управление доступом
Что откровенно порадовало - так это управление доступом.
Для удобства все пользователи могут разбиться по группам. У каждого юзера или группы могут быть права разных уровней - от полного отказа в доступе до полных прав, включая запись или создание ветки. В общем, вполне стандартные возможности.
Сами же права прописываются в виде текста, где перечисляются права на доступ, имя юзера или группы, IP-адрес или диапазон, для которого применимы права, и директория, на которые права прописываются (wildcards также применимы). Чем ниже правило, тем оно приоритетнее.
Простая схема, но она даёт все возможности для гибкого управления доступом.
Общее впечатление
Общее впечатление сейчас скорее положительное, несмотря на некоторые неудобства. Я бы сказал, что Perforce - это по сути сильно улучшенный Subversion с хорошим GUI. Но при этом платный.
По мере погружения в глубины Перфорса, наверное, что-то ещё напишу.
"Есть и побочный эффект, которого я не встречал нигде больше - меткой можно пометить одновременно два ответвления файловой структуры. Я пока не видел как бы это могло кому-то понадобиться, но в других системах это в принципе невозможно."
ОтветитьУдалитьВ том же ClearCase, например, уникальность метки - вещь настраиваемая на стороне сервера. Серверную часть Perforce'а ковырять не доводилось, но вполне допускаю, что в нем тоже это можно сконфигурировать.
О как. Не знал... Тогда перефразирую: в других системах "out of the box" это в принципе невозможно :)
ОтветитьУдалить