Использование Mercurial в большой организации
Некоторое время я использовал Mercurial для своих личных проектов, и мне это нравится. Мой работодатель рассматривает возможность перехода с CVS на SVN, но мне интересно, стоит ли мне вместо этого настаивать на Mercurial (или на некоторых других DVCS).
Один недостаток Mercurial заключается в том, что он, похоже, основан на идее иметь один репозиторий на "проект". В этой организации существуют десятки различных исполняемых файлов, библиотек DLL и других компонентов в текущем хранилище CVS, иерархически организованных. Существует много общих компонентов многократного использования, а также некоторые компоненты, специфичные для клиента, и конфигурации, специфичные для клиента. Текущие процедуры сборки обычно получают некоторый набор поддеревьев из хранилища CVS.
Если мы перейдем с CVS на Mercurial, каков наилучший способ организации репозитория / репозиториев? Должен ли мы иметь один огромный репозиторий Mercurial, содержащий все? Если нет, то насколько мелкозернистыми должны быть репозитории меньшего размера? Я думаю, что люди найдут это очень раздражающим, если им придется извлекать и загружать обновления из разных мест, но они также находят это раздражающим, если им приходится извлекать / выдвигать всю кодовую базу компании.
У кого-нибудь есть опыт с этим или совет?
Смежные вопросы:
3 ответа
AFAICS большая часть сопротивления любому из DVCSs исходит от людей, не понимающих, как их использовать. Часто повторяемое утверждение о том, что "нет центрального хранилища" очень страшно для людей, которые были заперты в модели CVS/SVN с незапамятных времен и не могут представить себе ничего другого, особенно для руководства и старших (опытных и / или циничные) разработчики, которые хотят сильного отслеживания и воспроизводимости исходного кода (и, возможно, также, если вы должны удовлетворять определенным стандартам в отношении ваших процессов разработки, как мы делали в месте, где я когда-то работал). Ну, у вас может быть центральное "благословенное репо" Вы просто не закованы в это. Например, для подгруппы легко на некоторое время настроить внутреннее репо на одной из рабочих станций.
Существует так много способов снять шкуру с пресловутой кошкой, что вам придется сесть и тщательно обдумать свой рабочий процесс. Подумайте о ваших нынешних практиках и силе, которую дает вам почти бесплатное клонирование и ветвление. Вероятно, что то, что вы делаете в настоящее время, будет развиваться, чтобы обойти ограничения модели типа CVS; будь готов сломать плесень. Возможно, вам понадобится назначить одного или двух чемпионов, чтобы облегчить всем переход; с большой командой вы, вероятно, захотите подумать об ограничении доступа коммитов для blessed.
На моей работе (небольшой дом программного обеспечения) мы перешли с CVS на hg и больше не возвращались. Мы используем его в основном централизованно. Преобразование нашего основного (древнего и очень большого) репо было болезненным, но это будет любым способом, которым вы идете, и когда это будет сделано, это будет сделано - будет намного легче изменить VCS позже. (Мы обнаружили ряд ситуаций, когда инструменты преобразования CVS просто не могут понять, что произошло; где чьи-то коммиты выполнялись лишь частично, а они не замечали в течение нескольких дней; разрешали ветки поставщиков; общее безумие и безумие, вызванное появлением времени задом наперед, не помогает фиксировать временные метки по местному времени из разных часовых поясов...)
Большое преимущество, которое я получил от DVCS, - это возможность делать ранние и частые коммиты, только когда они готовы. Когда я достигаю различных этапов работы, мне нравится проложить линию на песке, чтобы у меня было где-то, куда я мог бы вернуться, если нужно - но это не коммиты, которые должны быть представлены команде, поскольку они явно неполны бесчисленными способами. (Я делаю это в основном с ртутными очередями.) Все дело в рабочем процессе; Я никогда не мог бы сделать это с CVS.
Я думаю, вы уже знаете это, но если вы собираетесь отойти от CVS, вы можете сделать это намного лучше, чем SVN...
Для монолита или для модуля? Любая смена парадигмы будет непростой, независимо от того, с какой VCS вы работаете, с распределением или без; Модель CVS довольно специфична тем, что позволяет фиксировать файл за файлом, не проверяя актуальность остальной части репо (и не будем упоминать головную боль, которую, как известно, вызывали псевдонимы модулей).
- Работа с монолитными хранилищами может быть довольно медленной. Ваш vcs-клиент должен сканировать вашу копию всей вселенной на предмет изменений, а не только одного модуля. (Если вы работаете в Linux, посмотрите на расширение hg inotify, если вы еще этого не сделали.)
- Монолитный репо также вызывает ненужные условия гонки при фиксации (толкании). Это похоже на актуальную проверку CVS, но применяется ко всему репо: если у вас много активных разработчиков, часто совершающих коммиты, этот укусит вас.
Я бы предположил, что это стоит усилий, чтобы держаться подальше от монолитного, но имейте в виду, что это будет налагать свои собственные издержки с точки зрения дополнительной сложности в вашей системе сборки. (Примечание: если вы находите что-то утомительное, автоматизируйте это! Мы, программисты, в конце концов, ленивые существа.) Разделение вашего репо на все составляющие его модули может быть слишком экстремальным; может быть на полпути можно найти связанные компоненты, сгруппированные между небольшим количеством хранилищ. Вы также можете найти полезной поддержку субмодуля mercurial - " Вложенные репозитории" и " Расширение леса" (оба из которых я должен попытаться обдумать).
На прежнем рабочем месте у нас было несколько десятков компонентов, которые хранились как независимые модули CVS с довольно регламентированной метаструктурой. Компоненты объявляли то, от чего они зависели, и от каких сборочных частей они должны были экспортироваться; система сборки автоматически пишет make фрагменты, чтобы то, над чем вы работали, получало то, что ему нужно. Обычно это работало очень хорошо, и было довольно редко проваливать актуальную проверку CVS. (Был также чертовски сложный, но чрезвычайно мощный сборочный бот с минимальным отношением к разрешению зависимостей: он не пересобрал бы компонент, если бы уже был тот, который отвечал вашим требованиям. Добавьте к этим метакомпонентам, которые собрали установщики и все ISO-образы, и у вас есть хороший рецепт для простых сборок от начала и до конца, и для всего, что происходит. Ученик Sorcerers. Кто-то должен написать об этом книгу...)
Раскрытие: Это кросс-пост из другой ветки, посвященной git, но я все равно порекомендовал Mercurial. Он имеет дело с DVCS в корпоративном контексте в целом, поэтому я надеюсь, что кросс-постинг это нормально. Я немного изменил его, чтобы лучше соответствовать этому вопросу:
Вопреки общему мнению, я считаю, что использование DVCS является идеальным выбором в корпоративных условиях, поскольку оно обеспечивает очень гибкие рабочие процессы. Сначала я расскажу об использовании DVCS против CVCS, о лучших практиках, а затем о git в частности.
DVCS против CVCS в контексте предприятия:
Я не буду говорить об общих плюсах и минусах, а скорее остановлюсь на вашем контексте. Это распространенная концепция, что использование DVCS требует более дисциплинированной команды, чем использование централизованной системы. Это связано с тем, что централизованная система предоставляет вам простой способ обеспечить ваш рабочий процесс, а использование децентрализованной системы требует большей коммуникации и дисциплины, чтобы придерживаться установленных соглашений. Хотя может показаться, что это приводит к накладным расходам, я вижу выгоду в расширении коммуникаций, необходимых для того, чтобы сделать это хорошим процессом. Ваша команда должна будет сообщить о коде, об изменениях и о статусе проекта в целом.
Другое измерение в контексте дисциплины - поощрение ветвления и экспериментов. Вот цитата из недавней записи Мартина Фаулерса о средствах управления версиями, в которой он нашел очень краткое описание этого явления.
DVCS поощряет быстрое ветвление для экспериментов. Вы можете создавать ветки в Subversion, но тот факт, что они видны всем, не позволяет людям открывать ветки для экспериментальной работы. Точно так же DVCS поощряет проверку работы: внесение неполных изменений, которые могут даже не скомпилировать или пройти тесты, в ваш локальный репозиторий. Опять же, вы можете сделать это в ветке разработчика в Subversion, но тот факт, что такие ветки находятся в общем пространстве, делает людей менее склонными к этому.
DVCS обеспечивают гибкие рабочие процессы, поскольку они обеспечивают отслеживание изменений через глобальные уникальные идентификаторы в ориентированном ациклическом графе (DAG) вместо простых текстовых различий. Это позволяет им прозрачно отслеживать происхождение и историю изменений, что может быть довольно важным.
Workflows:
Ларри Остерман (разработчик Microsoft, работающий в команде Windows) имеет отличный пост в блоге о рабочем процессе, который они используют в команде Windows. В первую очередь они имеют:
- Чистый, качественный только код ствола (мастер репо)
- Все разработки происходят по тематическим веткам
- Особые команды имеют репозитории
- Они регулярно объединяют последние изменения соединительных линий в свою ветвь функций (Прямая интеграция)
- Полные функции должны пройти несколько качественных проверок, например, обзор, тестовое покрытие, вопросы и ответы (репо самостоятельно)
- Если функция завершена и имеет приемлемое качество, она объединяется в транк (обратная интеграция)
Как вы можете видеть, если каждый из этих репозиториев живет самостоятельно, вы можете разделить различные команды, продвигающиеся с разной скоростью. Также возможность реализации гибкой системы контроля качества отличает DVCS от CVCS. Вы также можете решить свои проблемы с разрешениями на этом уровне. Только горстка людей должна иметь доступ к главному репо. Для каждого уровня иерархии есть отдельное хранилище с соответствующими политиками доступа. Действительно, этот подход может быть очень гибким на командном уровне. Вы должны оставить за каждой командой право решать, хотят ли они разделить репо своей команды между собой или если они хотят более иерархического подхода, когда только командный лидер может взять на себя командное репо.
(Картинка украдена с http://hginit.com/ Джоэла Спольски.)
На данный момент остается сказать, что, хотя DVCS предоставляет отличные возможности слияния, это никогда не заменит использование непрерывной интеграции. Даже в этот момент у вас есть большая гибкость: CI для репо транка, CI для репозитория команды, репо Q&A и т. Д.
Mercurial в контексте предприятия:
Я не хочу начинать git и hg flamewar, вы уже на правильном пути, подумав о переходе на DVCS. Вот несколько причин использовать Mercurial вместо git:
- Все платформы, которые запускают Python, поддерживаются
- Великолепные инструменты GUI на всех основных платформах (win/linux/OS X), первоклассная интеграция инструментов слияния /vdiff
- Очень согласованный интерфейс, простой переход для пользователей SVN
- Может делать большинство вещей, которые может делать git, но обеспечивает более чистую абстракцию. Опасные операции всегда являются явными. Расширенные функции предоставляются через расширения, которые должны быть явно включены.
- Коммерческая поддержка доступна от Selenic.
Короче говоря, при использовании DVCS на предприятии я думаю, что важно выбрать инструмент, который вводит наименьшее трение. Чтобы переход был успешным, особенно важно учитывать разные навыки между разработчиками (в отношении VCS).
Есть пара ресурсов, на которые я хотел бы указать вам в конце. Джоэл Спольски недавно написал статью, опровергающую множество аргументов против DVCS. Следует отметить, что другие обнаружили эти контраргументы задолго до этого. Другой хороший ресурс - блог Эрика Синкса, где он написал статью о препятствиях для корпоративной DVCS.
Прежде всего, актуальна недавняя дискуссия об использовании DVCS в крупных проектах:
Распределенное управление версиями для ОГРОМНЫХ проектов - возможно ли это?
Один недостаток Mercurial заключается в том, что он, похоже, основан на идее иметь один репозиторий на "проект".
Да, в то время как нормой для Subversion является наличие одного монолитного репозитория, содержащего несколько проектов, в случае DVCS предпочтительно иметь более детализированные репозитории, по одному на компонент. Subversion имеет svn:externals функция агрегирования нескольких исходных деревьев во время оформления заказа (что имеет свои логистические и технические проблемы). И Mercurial, и Git имеют похожую функцию, называемую subrepos в hg.
Идея с подпунктами заключается в том, что у вас есть один репо на компонент, а выпускаемый продукт (включающий несколько повторно используемых компонентов) будет просто ссылаться на его зависимые репо. Когда вы клонируете репозиторий продукта, он приносит необходимые компоненты.
Должен ли мы иметь один огромный репозиторий Mercurial, содержащий все? Если нет, то насколько мелкозернистыми должны быть репозитории меньшего размера? Я думаю, что люди найдут это очень раздражающим, если им придется извлекать и загружать обновления из разных мест, но они также находят это раздражающим, если им приходится извлекать / выдвигать всю кодовую базу компании.
Конечно, возможно иметь один монолитный репозиторий (и вы можете даже разбить его по дорожке, если вам нужно). Проблемы с этим подходом, скорее всего, сводятся к выпуску расписаний и к тому, как вы управляете различными версиями разных компонентов. Если у вас есть несколько продуктов с их собственными графиками выпуска, совместно использующими общие компоненты, вам, вероятно, будет лучше использовать более детальный подход, чтобы упростить управление конфигурацией.
Одно из предостережений заключается в том, что поддержка субрепорта является относительно недавней функцией и не так полноценна, как другие функции. В частности, не все команды hg знают о подпунктах, хотя наиболее важные из них.
Я предлагаю вам выполнить тестовую конвертацию и поэкспериментировать с поддержкой суб-репо, организацией продуктов и зависимых компонентов и т. Д. Я делаю то же самое, и похоже, что это путь.