Использование Mercurial в крупной организации

Ответ 1

AFAICS большая часть сопротивления любому из DVCSes исходит от людей, которые не понимают, как их использовать. Часто повторяющееся утверждение о том, что "нет центрального хранилища" очень страшно для людей, которые с незапамятных времен были заблокированы в модели CVS/SVN и не могут представить ничего другого, особенно для руководства и старшего (опытных и/или циничные) разработчики, которые хотят сильного отслеживания и воспроизводимости исходного кода (и, возможно, также, если вам нужно соответствовать определенным стандартам в отношении ваших процессов разработки, как, например, в том месте, где я когда-то работал). Ну, вы можете иметь центральное "благословенное" репо; вы просто не привязаны к нему. Например, для подтемы легко создать внутреннюю репо на игровой площадке на одной из своих рабочих станций, например.

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

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

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

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

Монолит или модуль? Любой сдвиг парадигмы будет сложным, чем любой VCS, с которым вы работаете, распространяетесь или нет; CVS-модель довольно специфична в том, как она позволяет фиксировать файл по файлу без проверки того, является ли остальная часть репо актуальной (и не упоминайте головную боль, из-за которой известно, что псевдонимы модулей).

• Работа с монолитными репозиториями может быть довольно медленной. Ваш клиент vcs должен сканировать вашу копию всего юниверса для изменений, а не только одного модуля. (Если вы работаете в Linux, загляните в расширение hg inotify, если вы еще этого не сделали.)
• Монолитное репо также вызывает ненужные условия гонки при совершении (нажатии). Это похоже на обновленную проверку CVS, но применяется во всем репо: если у вас много активных разработчиков, которые часто совершают, этот вас укусит.

Я бы предположил, что это стоит усилий, чтобы держаться подальше от монолита, но будьте осторожны, что он наложит свои собственные накладные расходы с точки зрения дополнительной сложности в вашей системе сборки. (Обратите внимание: если вы найдете что-то утомительное занятие, автоматизируйте его! В конце концов, мы программисты - ленивые существа.) Разделение вашего репо на все его составные модули может быть слишком экстремальным; может быть найден неполный дом со связанными компонентами, сгруппированными между небольшим количеством хранилищ. Вы также можете счесть полезным взглянуть на поддержку меркуриального субмодуля - Вложенные репозитории и Forest Extension (оба из которых я должен попытаться развернуть).

На прежнем рабочем месте у нас было несколько десятков компонентов, которые были сохранены как независимые модули CVS с довольно упорядоченной метаструктурой. Компоненты заявили о том, на что они зависели, и какие изготовленные детали должны были экспортироваться туда; система сборки автоматически пишет фрагменты, чтобы то, над чем вы работали, забирало то, что нужно. Как правило, он работал очень хорошо, и было довольно редко сбой проверки CVS. (Существовал также дьявольски сложный, но чрезвычайно мощный бот с наименее затратным отношением к разрешению зависимостей: он не перестраивал бы компонент, если бы уже был тот, который соответствовал вашим требованиям. Добавьте к этому мета-компоненты, которые собирали инсталляторы и целые ISO-образы, и у вас есть хороший рецепт для простых старт-финишных сборок и для вещей, идущих к ученикам-волшебникам. Кто-то должен написать книгу об этом...)

Ответ 2

Раскрытие: это cross post из другого потока, который был сфокусирован вокруг git, но в любом случае я рекомендовал mercurial. Это касается DVCS в контексте предприятия в целом, поэтому я надеюсь, что перекрестная публикация будет прекрасной. Я немного изменил его, чтобы лучше подойти к этому вопросу:

По общему мнению, я считаю, что использование DVCS - идеальный выбор в настройках предприятия, поскольку он обеспечивает очень гибкие рабочие процессы. Я расскажу об использовании DVCS и CVCS, в первую очередь, о лучших практиках, а затем о git в частности.

DVCS против CVCS в контексте предприятия:

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

Другим аспектом в контексте дисциплины является поощрение ветвления и экспериментов. Здесь цитата из недавней записи в блоке Мартина Фаулера в средствах управления версиями, он нашел очень краткое описание этого явления.

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

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

Workflows:

Ларри Остерман (разработчик Microsoft, работающий над командой Windows) имеет отличный пост в блоге о рабочем процессе, который они используют в команде Windows. Наиболее заметно:

• Чистый, высококачественный код только магистрали (master repo)
• Все разработки происходят в ветвях функций
• Группы функций имеют командные репозитории
• Они регулярно объединяют последние изменения сундуков в свою ветку функций (Forward Integrate)
• Полные функции должны проходить через несколько качественных ворот, например. обзор, покрытие тестов, Q & A (репозиции самостоятельно)
• Если функция завершена и имеет приемлемое качество, она объединяется в туловище (Обратный интегратор)

Как вы можете видеть, каждый из этих репозиториев живет самостоятельно, вы можете разделить разные команды, продвигающиеся в разных темпах. Также возможность внедрения гибкой системы затворов качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к мастер-репо. Для каждого уровня иерархии есть отдельное репо с соответствующими политиками доступа. Действительно, этот подход может быть очень гибким на уровне команды. Вы должны оставить это в каждой команде, чтобы решить, хотят ли они поделиться своим репо между собой или если они хотят использовать более иерархичный подход, когда только команда может взять на себя ответственность за репо.

(Изображение украдено у Джоэла Спольского hginit.com.)

На данный момент остается сказать одно, даже несмотря на то, что DVCS обеспечивает отличные возможности слияния, это никогда не заменяет использование Continuous Integration. Даже в этот момент у вас есть большая гибкость: CI для ретрансляции транков, CI для командных репозиториев, Q & РЕПО и т.д.

Mercurial в контексте предприятия:

Я не хочу запускать здесь git vs. hg flamewar, вы уже на правильном пути, рассматривая переход на DVCS. Вот несколько причин использовать Mercurial вместо git:

• Поддерживаются все plattform, которые запускают python.
• Отличные инструменты графического интерфейса для всех основных платформ (win/linux/OS X), интеграция с интеграцией первого класса /vdiff
• Очень последовательный интерфейс, простой переход для пользователей svn
• Может делать большинство вещей, которые git может делать тоже, но обеспечивает более чистую абстракцию. Опасные операции всегда явны. Расширенные функции предоставляются через расширения, которые должны быть явно включены.
• Коммерческая поддержка доступна из селена.

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

Есть несколько ресурсов, на которые я хотел бы указать вам в конце. Недавно Джоэл Спольски написал статью статью, в которой победил много аргументов против DVCS. Следует упомянуть, что другие давно обнаружили эти противоречия. Другим хорошим ресурсом является блог Эрика Скинкса, в котором он написал статью о Препятствия для корпоративного DVCS.

Ответ 3

Прежде всего, актуальна недавняя дискуссия об использовании DVCS в огромных проектах:

Управление распределенной версией для HUGE-проектов - возможно ли это?

Одна морщина с Mercurial заключается в том, что она, по-видимому, спроектирована вокруг идеи создания единого репозитория на "проект".

Да, в то время как норма с Subversion должна иметь один монолитный репозиторий, содержащий несколько проектов, с DVCS предпочтительнее иметь более гранулированные репозитории, по одному на компонент. Subversion имеет функцию svn:externals для агрегирования нескольких исходных деревьев во время проверки (которая имеет свои логистические и технические проблемы). И Mercurial, и Git имеют аналогичную функцию, называемую subrepos в hg.

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

Должен ли мы иметь один огромный Mercurial-хранилище, содержащий все? Если нет, то насколько мелкозернистые должны иметь меньшие репозитории? Я думаю, что людям будет очень неприятно, если им придется тянуть и выталкивать обновления из разных мест, но они также будут раздражать, если им придется вытащить/протолкнуть всю кодовую базу.

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

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

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