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

Ответ 1

100 МБ исходного кода меньше, чем ядро ​​Linux. Список изменений между ядром 2.6.33 и 2.6.34-rc1 для Linux имеет 6604 фиксации. Шкала репозитория не кажется мне пугающей.

• Ядро Linux 2.6.34-rc1 несжато из архива .tar.bz2: 445MB
• Linux kernel 2.6 head извлечен из основного дерева Linus: 827MB

В два раза больше, но все равно арахисы с большими жесткими дисками, которые у всех есть.

Ответ 2

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

Абсолютно! Как вы знаете, 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 предназначен для сырой скорости. Формат на диске, проводной протокол, алгоритмы в памяти полностью оптимизированы. И они разработали сложные рабочие процессы, где исправления распространяются от отдельных разработчиков, вплоть до подсистемы, до лейтенантов, и в конечном итоге до Linus. Одна из лучших вещей в DVCS заключается в том, что они настолько гибкие, что позволяют выполнять всевозможные рабочие процессы.

Я предлагаю вам прочитать отличную книгу о Mercurial от Брайана О'Салливана, которая поможет вам быстро подняться. Загрузите Mercurial и поработайте с примерами и поиграйте с ним в каких-то репозиториях с нуля, чтобы почувствовать его.

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

Ответ 3

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

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

Ответ 4

Ты говоришь, что доволен SVN... так зачем менять?

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

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

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

Ответ 5

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

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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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

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