Распределенное управление версиями для ОГРОМНЫХ проектов - возможно ли это?
Мы сейчас очень довольны SVN, но урок Джоэла заинтриговал меня. Поэтому мне было интересно - будет ли это осуществимо и в нашей ситуации?
Дело в том, что наше хранилище SVN ОГРОМНО. Само программное обеспечение имеет 15-летнее наследие и уже пережило несколько различных систем контроля версий. Существует более 68 000 ревизий (наборов изменений), сам источник занимает более 100 МБ, и я даже не могу догадаться, сколько ГБ использует весь репозиторий.
Тогда проблема проста - клону всего хранилища, вероятно, потребовались бы годы, и он занимал бы намного больше места на диске, который удаленно исправен. А так как суть распределенного контроля версий заключается в том, чтобы иметь столько репозиториев, сколько необходимо, я начинаю сомневаться.
Как Mercurial (или любой другой распределенный контроль версий) справляется с этим? Или они непригодны для таких огромных проектов?
Добавлено: Чтобы уточнить - все это один монолитный зверь проекта, который компилируется в один.EXE и не может быть разделен.
Добавлено 2: Вторая мысль - репозиторий ядра Linux использует git и, вероятно, на порядок или два больше моего. Так как они заставляют это работать?
10 ответов
100 МБ исходного кода меньше, чем ядро Linux. Журнал изменений между ядром Linux 2.6.33 и 2.6.34-rc1 имеет 6604 коммитов. Ваша шкала хранилища не кажется мне пугающей.
- Ядро Linux 2.6.34-rc1, несжатое из архива.tar.bz2: 445 МБ
- Голова ядра Linux 2.6 извлечена из основного дерева Линуса: 827 МБ
В два раза больше, но все еще арахис на больших жестких дисках у всех нас.
Распределенное управление версиями для ОГРОМНЫХ проектов - возможно ли это?
Абсолютно! Как вы знаете, Linux массивный и использует Git. Mercurial используется также для некоторых крупных проектов, таких как Python, Mozilla, OpenSolaris и Java.
Мы сейчас очень довольны SVN, но урок Джоэла заинтриговал меня. Поэтому мне было интересно - будет ли это осуществимо и в нашей ситуации?
Да. И если вы довольны Subversion сейчас, вы, вероятно, не делаете много разветвлений и слияний!
Дело в том, что наше хранилище SVN ОГРОМНО. [...] Существует более 68 000 ревизий (наборов изменений), сам источник занимает более 100 МБ
Как уже отмечали другие, это на самом деле не так уж много по сравнению со многими существующими проектами.
Тогда проблема проста - клону всего хранилища, вероятно, потребовались бы годы, и он занимал бы намного больше места на диске, который удаленно исправен.
И Git, и Mercurial очень эффективны в управлении хранилищем, а их репозитории занимают гораздо меньше места, чем эквивалентные репозитории Subversion (в которых конвертировано несколько). И как только у вас есть начальная проверка, вы только толкаете дельты вокруг, что очень быстро. Они оба значительно быстрее в большинстве операций. Первоначальный клон - единовременная стоимость, поэтому не имеет значения, сколько времени это займет (и я уверен, вы будете удивлены!).
А так как суть распределенного контроля версий заключается в том, чтобы иметь столько репозиториев, сколько необходимо, я начинаю сомневаться.
Дисковое пространство дешево. Производительность разработчиков важнее. Так что, если репо занимает 1 ГБ? Если вы можете работать умнее, оно того стоит.
Как Mercurial (или любой другой распределенный контроль версий) справляется с этим? Или они непригодны для таких огромных проектов?
Вероятно, стоит прочитать о том, как проекты, использующие Mercurial, такие как Mozilla, управляли процессом преобразования. Большинство из них имеют несколько репозиториев, каждый из которых содержит основные компоненты. Mercurial и Git также поддерживают вложенные репозитории. И есть инструменты для управления процессом конвертации - Mercurial имеет встроенную поддержку для импорта из большинства других систем.
Добавлено: Чтобы уточнить - все это один монолитный зверь проекта, который компилируется в один.EXE и не может быть разделен.
Это облегчает задачу, поскольку вам нужен только один репозиторий.
Добавлено 2: Вторая мысль - репозиторий ядра Linux использует git и, вероятно, на порядок или два больше моего. Так как они заставляют это работать?
Git предназначен для грубой скорости. Формат на диске, проводной протокол, алгоритмы в памяти сильно оптимизированы. Кроме того, они разработали сложные рабочие процессы, в которых патчи передаются от отдельных разработчиков, сопровождающих подсистем, вплоть до лейтенантов и, в конечном итоге, до Линуса. Одна из лучших особенностей DVCS заключается в том, что они настолько гибки, что допускают все виды рабочих процессов.
Я предлагаю вам прочитать отличную книгу Брайана О'Салливана о Mercurial, которая поможет вам быстро набрать скорость. Скачайте Mercurial и поработайте с примерами, и поиграйте с ним в некоторых скрэш-репозиториях, чтобы почувствовать это.
Затем запустите convert Команда для импорта вашего существующего исходного хранилища. Затем попробуйте внести некоторые локальные изменения, коммиты, ветки, просмотреть журналы, использовать встроенный веб-сервер и так далее. Затем клонируйте его в другую коробку и внесите изменения. Определите время наиболее распространенных операций и посмотрите, как они сравниваются. Вы можете сделать полную оценку бесплатно, но потратить некоторое время.
Не беспокойтесь о требованиях к хранилищу. Мой анекдот: когда я преобразовал нашу кодовую базу из SVN в git (полная история - я думаю), я обнаружил, что клон использовал меньше места, чем просто рабочий каталог WVN. SVN сохраняет нетронутую копию всех ваших извлеченных файлов: посмотрите на $PWD/.svn/text-base/ в любой проверке SVN. С git вся история занимает меньше места.
Что действительно удивило меня, так это то, насколько эффективен Git для работы в сети. Я сделал git-клон проекта в хорошо связанном месте, а затем забрал его домой на флэш-диск, где я постоянно обновляю его git fetch / git pull, только с моим маленьким маленьким GPRS-соединением. Я бы не посмел сделать то же самое в проекте, контролируемом SVN.
Вы действительно должны это себе, чтобы хотя бы попробовать. Я думаю, вы будете удивлены тем, насколько ошибочными были ваши предположения, связанные с централизованным VCS.
Вы говорите, что довольны SVN... так зачем менять?
Что касается распределенных систем контроля версий, Linux использует git, а Sun - Mercurial. Оба являются впечатляюще большими хранилищами исходного кода, и они прекрасно работают. Да, вы получаете все изменения на всех рабочих станциях, но это цена, которую вы платите за децентрализацию. Помните, что хранилище стоит дешево - мой ноутбук для разработки в настоящее время имеет 1 ТБ (2x500 ГБ) жесткого диска на борту. Вы тестировали подтягивание своего репозитория SVN в нечто вроде Git или Mercurial, чтобы реально увидеть, сколько места это займет?
Мой вопрос: готовы ли вы, как организация, перейти к децентрализации? Для магазина программного обеспечения обычно имеет смысл иметь центральное хранилище (регулярное резервное копирование, подключение к CruiseControl или FishEye, более простое управление и администрирование).
И если вы просто хотите что-то более быстрое или более масштабируемое, чем SVN, просто купите коммерческий продукт - я использовал и Perforce, и Rational ClearCase, и они без проблем масштабируются до огромных проектов.
Тебе нужна вся история? Если вам нужен только последний год или два, вы можете оставить текущий репозиторий в состоянии "только чтение" для исторической справки. Затем создайте новый репозиторий с только недавней историей, выполнив дамп svnadmin с ревизией нижней границы, которая является основой для вашего нового распределенного репозитория.
Я согласен с другим ответом, что 100 МБ рабочей копии и 68 КБ версий не так уж велики. Дать ему шанс.
Вы бы разбили свой один огромный репозиторий на множество небольших репозиториев, каждый для каждого модуля в вашем старом репо. Таким образом, люди будут просто хранить в качестве репозиториев те проекты SVN, которые у них были до этого. Не намного больше места, чем раньше.
Я использую git для довольно большого проекта C#/.NET (68 проектов в 1 решении), и объем TFS для новой выборки полного дерева составляет ~500Mb. Репозиторий git, хранящий достаточное количество коммитов локально, весит ~800Mb. Сжатие и внутренняя работа хранилища в git превосходны. Удивительно видеть так много изменений, упакованных в такое маленькое пространство.
Git, очевидно, может работать с таким большим проектом, как ваш, поскольку, как вы указали, только ядро Linux больше.
Сложность (не знаю, управляете ли вы большими файлами) с Mercurial и Git заключается в том, что они не могут управлять большими файлами (пока).
У меня есть опыт переноса проекта вашего размера (и около 15 лет) из CVS/SVN (на самом деле это смесь из двух) в Plastic SCM для распределенного и централизованного (эти два рабочих процесса происходят внутри одной организации одновременно) развитие.
Этот шаг никогда не будет беспроблемным, поскольку это не только техническая проблема, но и вовлечение большого количества людей (такой большой проект, как ваш, возможно, включает несколько сотен разработчиков, не так ли?), Но есть импортеры, которые могут автоматизировать миграцию, и обучение может быть сделано очень быстро тоже.
Из моего опыта, Mercurial довольно хорошо справляется с большим количеством файлов и огромной историей. Недостатком является то, что вы не должны регистрировать файлы размером более 10 Мб. Мы использовали Mercurial для хранения истории нашей скомпилированной DLL. Не рекомендуется помещать двоичные файлы в исходный счетчик, но мы все равно попробовали (это был репозиторий, предназначенный для двоичных файлов). В хранилище было около 2 гигабайт, и мы не слишком уверены, что сможем продолжать делать это в будущем. Во всяком случае, для исходного кода я не думаю, что вам нужно беспокоиться.
Нет не работает. Вам не нужно ничего, что требует значительного хранилища на стороне клиента. Если вы получите такой большой размер (с помощью повторного примера изображений и т. Д.), Хранилище требует большего, чем у обычной рабочей станции, в любом случае для эффективности.
Тогда вам лучше пойти с чем-то централизованным. Простая математика - просто невозможно, чтобы на каждом рабочем месте было много гигабайтов и быть там эффективным. Это просто не имеет смысла.