Распределенное управление версиями для ОГРОМНЫХ проектов - действительно ли это выполнимо?

Вы бы разбили свой один огромный репозиторий на множество меньших репозиториев, каждый для каждого модуля в вашем старом репо. Таким образом, люди будут просто хранить в качестве репозиториев любые проекты SVN, которые у них были бы раньше. Требуется не намного больше места, чем раньше.

По моему опыту, Mercurial довольно хорошо справляется с большим количеством файлов и огромной историей. Недостатком является то, что файлы размером более 10 Мб не должны регистрироваться. Мы использовали Mercurial для ведения истории нашей скомпилированной DLL. Не рекомендуется помещать двоичные файлы в исходный countrol, но мы все равно попробовали (это был репозиторий, посвященный двоичным файлам). Размер репозитория был около 2 гигабайт, и мы не очень уверены, что сможем продолжать делать это в будущем. В любом случае, я не думаю, что вам стоит беспокоиться об исходном коде.

Нужна ли вам вся история? Если вам нужен только последний год или два, вы можете оставить текущее хранилище в состоянии "только для чтения" для исторической справки. Затем создайте новое хранилище только с недавней историей, выполнив svnadmin dump с нижней граничной ревизией, которая станет основой для вашего нового распределенного хранилища.

Я согласен с другим ответом, что 100MB рабочей копии и 68K ревизий - это не так уж и много. Попробуйте.

Распределенный контроль версий для ОГРОМНЫХ проектов - возможно ли это?

Абсолютно! Как вы знаете, 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... так зачем менять?

Что касается распределенных систем контроля версий, Linux использует git, а Sun - Mercurial. Обе эти системы являются впечатляюще большими хранилищами исходного кода, и они работают просто отлично. Да, в итоге вы получаете все ревизии на всех рабочих станциях, но это цена, которую вы платите за децентрализацию. Помните, что хранение дешево - мой ноутбук для разработки в настоящее время имеет 1 ТБ (2x500 ГБ) жесткого диска на борту. Вы тестировали перенос вашего SVN-репозитория во что-то вроде Git или Mercurial, чтобы действительно увидеть, сколько места это займет?

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

А если вам просто нужно что-то более быстрое или более масштабируемое, чем SVN, то просто купите коммерческий продукт - я использовал и Perforce, и Rational ClearCase, и они без проблем масштабируются до огромных проектов.

Я использую git в довольно большом проекте c # /. Net (68 проектов в 1 решении) и занимаю место в TFS при свежей выборке полного дерева составляет ~ 500Мб. Репозиторий git, в котором хранится изрядное количество коммитов локально, весит ~ 800 МБ. Сжатие и способ внутренней работы хранилища в git превосходны. Удивительно видеть столько изменений, упакованных в такой небольшой объем.

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

Тогда вам лучше пойти с чем-нибудь централизованным. Простая математика - просто нереально иметь тонну гигабайта на каждой рабочей станции и быть там эффективным. Это просто бессмысленно.

Git, очевидно, может работать с таким большим проектом, как ваш, поскольку, как вы указали, одно только ядро Linux больше.

Проблема (не знаю, если вы работаете с большими файлами) с Mercurial и Git в том, что они не могут работать с большими файлами (пока что).

У меня есть опыт перемещения проекта вашего размера (и тоже в течение 15 лет) с CVS/SVN (на самом деле смесь этих двух) на Plastic SCM для распределенной и централизованной (эти два рабочих процесса происходят в одной организации в одно и то же время) разработки.

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

Не беспокойтесь о требованиях к пространству хранилища. Мой анекдот: когда я перевел нашу кодовую базу с SVN на git (полная история - я думаю), я обнаружил, что клон использует меньше места, чем просто рабочий каталог WVN. SVN хранит нетронутую копию всех ваших проверенных файлов: посмотрите на $PWD/.svn/text-base/ в любом SVN checkout. В git вся история занимает меньше места.

Что меня действительно удивило, так это то, насколько git эффективен в сети. Я сделал git-клон проекта в хорошо подключенном месте, затем взял его домой на флэш-диск, где я поддерживаю его в актуальном состоянии с помощью git fetch / git pull, используя только мое маленькое GPRS-соединение. Я бы не осмелился сделать то же самое в проекте, контролируемом SVN.

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